[PATCH] mobile: divedetails page etc. improvements

[Sebastian Kügler]

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.

Cheers,
-- 
sebas

Sebastian Kügler    |    http://vizZzion.org    |     http://kde.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: item.qml
Type: text/x-qml
Size: 83 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151116/bbaab3f2/attachment.bin>