Kirigami 1.0 feedback

[Dirk Hohndel]

-- 
Sent from my phone
> On Apr 3, 2016, at 11:11, Marco Martin <notmart at gmail.com> wrote:
> 
> 
>> 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

It just looks odd that the button moves and the handles don't. And the button definitely should move so you don't need to hide the keyboard to save for example.

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

Thanks. It seemed strange, but maybe it's a bug in our code. 

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

I'm on my phone at the airport and don't know when I'll have internet for my computer again, so feel free to apply the patch as is and the rename the property...


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

Well, doesn't need to be blurred home screen. Could be the blurred copy of what you are moving. Or just an oddly shaded area. Just so it looks intentional. 
> 
>> 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)

That works. In the current version that I sent and with the way Subsurface-mobile uses it it works as bread crumbs. Only if you are scrolled down on dive list (which hides the crumbs), then a tap "up there" gets you back to the top of the list. Which shows the title bar, which then works as bread crumbs again since you are already at the top. 

It did feel quite intuitive to me. 
> 
>> 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..

I'd like at least four so I can replace the context menu spot with a single button instead 

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

Yes. And cornerAction for the one replacing the context menu handle :-)

/D