On Wednesday, January 06, 2016 08:11:47 PM Kai Uwe Broulik wrote:
> > qinputmethod does have keyboard geometry even in 5.5, on linux it works
>
> fine... so that doesn't work on android?
>
> Yes, Google in their infinite wisdom believe that an app should never ever
> need to probe for the keyb
On Wednesday, January 06, 2016 10:48:10 AM Dirk Hohndel wrote:
> On Wed, Jan 06, 2016 at 04:39:33PM +0100, Marco Martin wrote:
> > On Wednesday 06 January 2016, Dirk Hohndel wrote:
> > > Building for Android is painful (as Sebastian will confirm). Adding
> > > something where an application after b
On Dienstag, 5. Januar 2016 18:15:38 CET Dirk Hohndel wrote:
> Wow. I did not realize that. Just tried it and indeed, you are right.
> No conflict, no issue. Cool.
Great! :-)
> I learned something new today :-)
Yeah, it seems Android could use some tutorials, too ;)
> > > What do you think abo
On Wed, Jan 06, 2016 at 08:03:16PM +0100, Marco Martin wrote:
> On Wednesday 06 January 2016, Marco Martin wrote:
> > On Wednesday 06 January 2016, Kai Uwe Broulik wrote:
> > > Hi,
> > >
> > > The issue with the virtual keyboard shifting the contents on Android is
> > > an issue I also face with p
> qinputmethod does have keyboard geometry even in 5.5, on linux it works
fine... so that doesn't work on android?
Yes, Google in their infinite wisdom believe that an app should never ever
need to probe for the keyboard geometry, only in 5.6 (or even 5.7, can't find
the codereview right now)
On Wednesday 06 January 2016, Marco Martin wrote:
> On Wednesday 06 January 2016, Kai Uwe Broulik wrote:
> > Hi,
> >
> > The issue with the virtual keyboard shifting the contents on Android is
> > an issue I also face with pure Qt apps and as of now there is no way to
> > prevent or detect this be
On Wednesday 06 January 2016, Kai Uwe Broulik wrote:
> Hi,
>
> The issue with the virtual keyboard shifting the contents on Android is an
> issue I also face with pure Qt apps and as of now there is no way to
> prevent or detect this behavior, at least not with Qt APIs.
>
> I think Qt 5.6 will pr
Have a look at Qt.inputMethod.visible and Qt.inputMethod.keyboardRectangle -
with that you should be able to transform the FAB so it stays visible on screen.
I'm not sure if you can influence the behavior that Android shifts the view
upwards if you tab an input field that would otherwise be cove
> On Jan 6, 2016, at 10:55, Kai Uwe Broulik wrote:
>
> Hi,
>
> The issue with the virtual keyboard shifting the contents on Android is an
> issue I also face with pure Qt apps and as of now there is no way to prevent
> or detect this behavior, at least not with Qt APIs.
>
> I think Qt 5.6 w
with which we could improve the experience in this regard.
Cheers,
Kai Uwe
Originalnachricht
Von: Dirk Hohndel
Gesendet: Mittwoch, 6. Januar 2016 19:52
An: plasma-devel@kde.org
Antwort an: plasma-devel@kde.org
Betreff: Re: some feedback from a mobile application development team
On Wed, Jan 06
On Wed, Jan 06, 2016 at 05:41:27PM +0100, Marco Martin wrote:
> On Wednesday 06 January 2016, Dirk Hohndel wrote:
> >
> > Well, before we removed the FAB I was quite easily able to get into
> > situations where the FAB would disappear and would not show back up,
> > regardless what I tried. The to
On Wed, Jan 06, 2016 at 04:39:33PM +0100, Marco Martin wrote:
> On Wednesday 06 January 2016, Dirk Hohndel wrote:
> > Building for Android is painful (as Sebastian will confirm). Adding
> > something where an application after being started downloads other
> > components... not going to happen. At
On Wednesday 06 January 2016, Dirk Hohndel wrote:
>
> Well, before we removed the FAB I was quite easily able to get into
> situations where the FAB would disappear and would not show back up,
> regardless what I tried. The top bar doesn't disappear, so those buttons
> are always there. Yet one mo
On Wednesday 06 January 2016, Dirk Hohndel wrote:
> This depends where you are planning to focus on when it comes to
> relevance. If you believe that plasma-mobile will be the next Android and
> that the next billion devices will run plasma-mobile, then I see your
> point. If you want Qt/QML/plasma
On Wednesday 06 January 2016, Dirk Hohndel wrote:
> Building for Android is painful (as Sebastian will confirm). Adding
> something where an application after being started downloads other
> components... not going to happen. At least not for Subsurface. I want to
> be able to offer the user an .ap
On Wed, Jan 06, 2016 at 11:14:18AM +0100, Marco Martin wrote:
> On Wednesday 06 January 2016, Thomas Pfeiffer wrote:
> > Therefore what I'd like to see is that when our components are used within
> > Android, they draw the buttons in the top bar (where they are - and that is
> > a research-supporte
On Wed, Jan 06, 2016 at 11:29:16AM +0100, Marco Martin wrote:
>
> > > Therefore what I'd like to see is that when our components are used
> > > within Android, they draw the buttons in the top bar (where they are -
> > > and that is a research-supported fact - hard to reach, but consistent
> > > w
On Wed, Jan 06, 2016 at 11:58:30AM +0100, Marco Martin wrote:
> > I will talk to Sebastian about synching our code base with upstream again
> > and hope that I can help contribute to the upstream project.
>
> One thing I would love to see, is the components downloaded and built at
> setup
> time
On Wednesday 06 January 2016, Thomas Pfeiffer wrote:
> Another thing I want to see changed in our components, though is the
> actual dragging interaction with the FAB. Currently one has to drag it
> pretty far to open a drawer, which defeats the whole "Not having to
> stretch your thumb to a corne
On Tuesday 05 January 2016, Dirk Hohndel wrote:
> Hi there,
>
> I just subscribed so please bear with me if I'm going over things that
> have been discussed.
Welcome aboard Dirk!
> The Subsurface team would love to see an option to cleanly disable the
> action button in the MobileComponents.
>
On Wednesday 06 January 2016, Thomas Pfeiffer wrote:
> > Support a "first start" mode for Plasma Mobile Components based apps that
> > demonstrates to the user how things get used. So it shows a see through
> > finger that taps and holds (the pulsing circles around the touch area)
> > the FAB and m
On Wednesday 06 January 2016, Dirk Hohndel wrote:
> Side note: I am not a huge friend of the side swipes being used for the
> drawers. I find swipes a great way to do navigation. There are a bunch of
> email applications where swiping left and right you can move to the
> previous / next item in you
On Wednesday 06 January 2016, Thomas Pfeiffer wrote:
> Therefore what I'd like to see is that when our components are used within
> Android, they draw the buttons in the top bar (where they are - and that is
> a research-supported fact - hard to reach, but consistent with other
> Android applicatio
Hi Thomas
On Wed, Jan 06, 2016 at 02:56:09AM +0100, Thomas Pfeiffer wrote:
You clearly have interesting working hours... just like Sebastian
> There is a difference between edge swipe and regular horizontal swipes. All
> stock Android apps that have a lef
On Dienstag, 5. Januar 2016 16:58:10 CET Dirk Hohndel wrote:
> Hi Thomas,
>
> > On Jan 5, 2016, at 3:22 PM, Thomas Pfeiffer
> > wrote: as the person in charge of the KDE Mobile HIG (and therefore also
> > responsible for the usability of the Plasma Components), I'm very happy
> > to get feedback
Hi Thomas,
> On Jan 5, 2016, at 3:22 PM, Thomas Pfeiffer wrote:
> as the person in charge of the KDE Mobile HIG (and therefore also responsible
> for the usability of the Plasma Components), I'm very happy to get feedback
> from users of an actual working application using our components!
Awes
On Dienstag, 5. Januar 2016 08:16:38 CET Dirk Hohndel wrote:
> Hi there,
Hi Dirk,
as the person in charge of the KDE Mobile HIG (and therefore also responsible
for the usability of the Plasma Components), I'm very happy to get feedback
from users of an actual working application using our compon
Hi there,
I just subscribed so please bear with me if I'm going over things that
have been discussed.
Some background for context:
Subsurface is a reasonably popular open source dive log program aimed
primarily at scuba divers. It's somewhat known in open source circles as
it was started by Linu
28 matches
Mail list logo
