On Monday 04 April 2016, Dirk Hohndel wrote:
> > As I already stated in my reply to sebas: Yes, you have convinced me that
> > a back button makes sense for iOS. And yes, having it somewhere in
> > between other buttons doesn't feel right, so the usual top-left corner
> > makes sense. I don't think
> On Apr 4, 2016, at 08:08, Thomas Pfeiffer wrote:
>
> On Sonntag, 3. April 2016 23:35:29 CEST Dirk Hohndel wrote:
>>>
>> My current thinging is that I may end up doing just that in the iOS
>> version. Having a back button somewhere that isn't a corner feels very
>> weird when I play with it.
On Monday 04 April 2016, Thomas Pfeiffer wrote:
> Yes, I agree. Let iOS users have their hard-to reach button, they're used
> to it anyway and - as Robert Helling's post on the Subsurface mailing list
> hints o - many or most of them have probably already adapted the way they
> hold their devices t
On Sonntag, 3. April 2016 23:35:29 CEST Dirk Hohndel wrote:
> > Is deleting a dive using the context drawer so unwieldy that it has to be
> > avoided at all cost?
>
> I actually have found that it's good that you challenge my ideas here...
> I looked at a bunch of Android and iOS apps and at how t
On Montag, 4. April 2016 13:05:15 CEST Sebastian Kügler wrote:
> On Sunday, April 03, 2016 11:35:29 PM Dirk Hohndel wrote:
> > BUT (and you knew there would be one): Swipe for "back key" is hard for
> > us. We can't really do it when looking at dive details, and it feels
> > really alien to iOS use
On Mon, Apr 04, 2016 at 03:40:50PM +0200, Marco Martin wrote:
> On Sunday 03 April 2016, you wrote:
> > > 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 t
On Sunday 03 April 2016, you wrote:
> > 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
On Sunday, April 03, 2016 11:35:29 PM Dirk Hohndel wrote:
> BUT (and you knew there would be one): Swipe for "back key" is hard for
> us. We can't really do it when looking at dive details, and it feels
> really alien to iOS users. And the back key on iOS is always, always,
> always, in every app,
On Mon, Apr 04, 2016 at 03:02:05AM +0200, Thomas Pfeiffer wrote:
> On Sunday, 3 April 2016 11:42:31 CEST Dirk Hohndel wrote:
>
> > 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.
>
On Sunday, 3 April 2016 11:42:31 CEST Dirk Hohndel wrote:
> 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.
Yes, and our visual designer is already working on a background image/pattern
--
Sent from my phone
> On Apr 3, 2016, at 11:11, Marco Martin 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 m
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
On Sunday 03 April 2016, Dirk Hohndel wrote:
> I'm not sure if this is "good QML" - Marco or anyone, feel free to comment
> and improve. It took me an embarrassingly long time to make this work, but
> I consider this a learning experience (and I believe I learned a lot
> today).
I would like to gi
Responding to myself again... must be a sign of approaching senility...
On Sat, Apr 02, 2016 at 09:55:51AM -0500, Dirk Hohndel wrote:
> >
> > > I think this is our consolidated feedback:
> > >
> > > - make it an intentional action; stop at the top when scrolling, but when
> > > the user stops
On Sat, Apr 02, 2016 at 04:38:43PM +0200, Thomas Pfeiffer wrote:
> even though you addresses Marco, let me comment on your suggestions so Marco
> knows what's "Kirigami design approved":
Bad habit of mine to address one person instead of all of you...
> > I have spent quite a few hours on portin
On Freitag, 1. April 2016 22:44:03 CEST Dirk Hohndel wrote:
> Hi Marco,
Hi Dirk,
even though you addresses Marco, let me comment on your suggestions so Marco
knows what's "Kirigami design approved":
> I have spent quite a few hours on porting Subsurface-mobile to Kirigami
> 1.0 and playing with
Responding to myself to add some clarifications based on some more
discussions with some of the testers...
On Fri, Apr 01, 2016 at 10:44:03PM -0500, Dirk Hohndel wrote:
>
> 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
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
18 matches
Mail list logo
