Kirigami 1.0 feedback

[Marco Martin]

On Saturday 02 April 2016, Dirk Hohndel wrote:
> 1. handling the keyboard on iOS and Android - with Qt5.6 it's possible to
> do a better job at handling the bottom margin when the virtual keyboard
> opens and closes. I was able to still get this to go wrong occasionally,
> but I can't reproduce the error case, so my guess is that this is at least
> a massive improvement if not a fix. This is the first attached patch.

thanks, applied the patch

> 2. connected to this, if the keyboard opens, now the bottom of the page is
> the upper edge of the keyboard and the action button is shown at the right
> spot, but the drawer(s) and the drawer handle(s) are not moved up as well
> and as a result the drawer handles are hidden behind the keyboard.
> I looked at the code but didn't feel comfortable that I understood things
> in enough detail to try to fix this.

should be easily fixable, even tough I'm not sure if the action button/handles 
should be visible, or the open keyboard should be a more "modal" thing

> 3. it seems that the titlebar is drawn on top of the page in some
> situations. I hacked around this in Subsurface-mobile by adding extra top
> margin to pages where I noticed it (DiveDetailsView.qml), but this does
> seem like a bug to me.

the titlebar is on top of the contents, it has to be due that show/hide 
behavior.
tough  margins are computed within Page, so contents shouldn't be covered.
I'll take a look

> a) it would be really nice if it "snapped" to its natural position. So
> when you move it up and down (maybe to look at what all is there) and if
> you let go, it should jump back to a reasonable position, so if you pulled
> down but not far enough to flick if off the screen and then let go, the
> top of the sheet should snap back to the top (or just below the top) of
> the current page. And similarly if you push the sheet up and let go, have
> the bottom snap back into place.

yeah, makes sense, will take a look at that

> b) in order to be able to have the animations run when opening or closing
> the sheet one needs to call the open() and close() functions (makes sense).
> But if you want to open an OverlaySheet in a state transition all you can
> do is change properties, not call functions. Maybe there's a better way to
> do this, but I attached a patch that allows property changes to trigger
> the open() and close() functions.

the patch is fine, but I would prefer the property to be called "opened" that 
even if doesn't shound great, is the name of an analogous property for 
OverlayDrawer, so i would like to keep the naming consistent. can you adapt 
it? or i can push then rename

> 
> 5. the margin at the top when pulling down a list (e.g., our dive list)
> seems HUGE and unintuitive. It really looks like a bug to the user. But
> then Thomas explained what this was intended to do and it suddenly made
> sense. This exists in iOS as well; but there when you trigger it (not by
> pulling down but by a soft double tap on the magic button / finger print
> sensor) then the whole app jumps about as far down as you do (so my
> comment about HUGE may be wrong), but it shows the background behind the
> app and seriously blurs it to indicate that this is more than just white
> space, this is moving part of the screen closer to your thumb. Maybe you
> could do something similar?  Change the background for the margin that you
> create there? Or move the title bar down as well with the upper end of the
> page and have something blurred out above?

the blurred part may be not possible (i guess that functionality on ios blurs 
the homescreen, that would have to be done by the operating system itself)

> 6. the title bar is really cool - and thanks for providing the properties
> to control the min/preferred/max sizes. It would be neat if the
> application could get a tap event if the user taps on the title bar, If it
> handles it, then don't interpret this as navigation on the bread crumbs.
> But if the application doesn't handle it, then do. I guess this could be
> similar to the way you handle the back button? So a signal "titleTapped"
> or something like that?

I think that if it looks like a breadcrumb it should behave like a 
breadcrumb...
One thing i would try to do instead is to split it into an abstract empty 
version that only provides the look and behavior on scrolling and a 
specialized version with the breadcrumb, so an application can replace it with 
a different custom subclass)

> 7. as discussed at great length on the Subsurface list, I'd really want a
> couple more buttons :-)
> My preference would be to have five button positions. (hey, one can dream)
> 
> left    halfleft    center    halfright    right
> 
> The left and right buttons are each mutually exclusive with having a
> globalDrawer or a contextDrawer (respectively). So if the page defines
> both a right button and a contextDrawer, that's an error (and I guess the
> drawer simply gets preference). But even with both drawers available, that
> would give us three action buttons. Maybe there could be the option to
> have the center button be a little bigger - if it is the obvious, natural
> default action, but I'm not sure how that would look. Same size or
> LARGE small LARGE small LARGE might make sense...

I would let it to be three at most..

The action button is done by settng an action property to the Page.
so would be other two properties
secondaryAction
thirdAction  ?


-- 
Marco Martin