Subsurface-mobile port to Kirigami 1.0

[Dirk Hohndel]

On Fri, Apr 01, 2016 at 10:04:36PM +0200, Marco Martin wrote:
> > 
> > - dynamic title bar... cute, but too extreme - this needs to be
> >   configurable from the application; right now it seems that the three
> >   factors (0, 1.6, 3) are hard coded in the Kirigami sources (or I'm
> >   misunderstanding how this works)
> 
> should be customizable by changing 
> Layout.minimumHeight/preferredHeight/maximumHeight of the ApplicationHeader 
> component.

Yes, I looked at the sources, that's how I found the hard coded values.
But our goal was to use an unchanged upstream Kirigami, right? So this
needs to be configurable in the application, not by modifying Kirigami
sources.

> I've now changed it to have directly minimum/preferred/maximum properties, so 
> it can be assigned directly in a declarative way:
> 
> ApplicationWindow {
> 
>  header.minimumHeight: whatever
>  header.preferredHeight: whatever
>  header.maximumHeight: whatever
> 
> }
> (putting the same would make it effectively fixed)

YES! Thank you. I need to pull the latest Kirigami (just woke up from an
after dive nap to find all your emails... the morning dives were rather
tiring... ripping current and way too much swimming against it).

> > - bread crumbs... certainly useful for many other applications, for us I'm
> >   not so sure. I think I'd prefer what we had before in that tapping on
> >   the title bar gets you to the top of the dive list. Of course you could
> >   allow the application to intercept the tap on the title bar and have it
> >   decide whether it wants to accept the event or not - that would be the
> >   best of both worlds, I guess
> 
> I could try to split the component in an abstract part that implements just 
> the titlebar look and a specialization that does the breadcrumb, so 
> applications could change it easily with an own implementation when needed

Cool. If this is indeed something you'd consider, can you provide an easy
mechanism where the app can register an action when the title bar is
clicked? So if it isn't using the breadcrumbs, the app could set up an
action that is activated if the user taps / clicks on the title bar, just
like with the action button? That would be nice and clean an flexible.

Because in general I like the design of the disappearing (and reappearing)
title bar!

> > - scrolling and flicking of pages... oh my.
> >   -- I sometimes get a huge empty space at the top of the dive list, not
> >      sure how to describe this, it's like a massive margin or something -
> >      I think this happens if I pull the list down; something similar
> >      happens with some other pages like the About page or developer log;
> >      pull down, you suddenly have the top third of the page as empty
> >      margin
> 
> having lists that can be scrolled down to leave empty areas is the behavior i 
> was asked by the designers, again to reach the topmost item with the thumb for 
> one handed use (Thomas can explain better).

Yes, the explanation made perfect sense. This just needs to be app
configurable as I mentioned in my earlier email.

> >   -- I still get the confused list at the bottom of the dive list with
> >      white areas and scrolling going all crazy on you

This really needs to be fixed, please. I'll be happy to help / make
adjustments to Subsurface-mobile to deal with this, but right now it's
really annoying and gives Subsurface-mobile a rather buggy feel.

> >   -- The weirdest one is that I can flick away some pages. So for example
> >      I go to add dive or edit a dive. Then the add/edit dive page is like
> >      an overlay on top of the other pages. And I can literally flick it
> >      away. Subsurface-mobile still things it is in editing stage and
> >      things get royally confused. This bug I think is the biggest reason
> >      why I'm not pushing this to our unsuspecting testers.
> 
> yes, that's how that component should work (is pretty much a scrollable modal 
> dialog). but of course, when is flicked away it should go out of edit 
> mode(reproducible in the apk you provided), so 
> that is indeed a bug.

What I need is once again a call back that tells me "this was flicked
away".

> is familiar with a similar component in ios and currently going in/out the 
> edit mode changes the whole screen "magically" without any transition, that is 
> usually not recommended in mobile applications.

Not sure I understand what you are saying here, can you try again - it
looks like maybe a part of the sentence got lost editing?

> > This needs a lot more testing but it's late (yeah, only 11, but I have to
> > go diving tomorrow... oh how I suffer). So please take a look at the APK
> > or build from sources...
> > 
> > Not sure what the best path forward is. Any chance that you have some time
> > to address these concerns, either in Kirigami or (where necessary) in
> > Subsurface?
> 
> sure, where patches to subsurface would go?, in a branch?

Oh, I'll merge this into master the moment this feels like it's
approaching useful. Last night I was mostly too tired to think straight.
The downside of dive trips (when you are old and decrepit)... you are
tired a lot...

So patches go to the mailing list as usual the branch will disappear
shortly.

Or did you mean patches for Kirigami? So far the things we've observed and
discussed here all seem like they should go into Kirigami master as
well...

/D