Kirigami 1.0 feedback

Sat Apr 2 03:44:03 UTC 2016

Hi Marco,

I have spent quite a few hours on porting Subsurface-mobile to Kirigami
1.0 and playing with the new features and options. I think this is coming
along nicely. Many of the new things I like, the new naming feels natural,
this is really a huge step forward.

But of course, if I'm writing an email like this, there are still a few
things that I think could be improved.

I have two patches that make a big difference in usability for
Subsurface-mobile and a few bug reports and requsts for features...

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.

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.

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.

4. the OverlaySheet is nice. I like the functionality and the intuitive
way to get rid of it. And I figured out that I can already tell when it
gets flicked off-screen so that I can exit edit mode, so this is mostly
good. But there are two issues:
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.
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.

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?

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?

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...

Ok, long email, lots of content, many ideas, many requests. At least I am
bringing along two patches and I hope the issues that I report make sense
and help to make Kirigami better!

Thanks for all your hard work on this

/D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-keyboard-area-hack-for-Qt-5.6.patch
Type: text/x-diff
Size: 1282 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160401/e302b088/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Trigger-OverlaySheet-open-and-closed-by-PropertyChan.patch
Type: text/x-diff
Size: 1273 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160401/e302b088/attachment-0001.patch>