Out of the serialisation discussion at QtCS 2018, we have a call for action to
discuss the possibility of *not* adding QCborValue in Qt 5.12 and instead add
a generic, data model API that could be used for JSON, CBOR and future uses.
The reason was that we do not need the duplication of very
> On 13 Jun 2018, at 14:07, Simon Hausmann wrote:
>
> Hi,
>
> While it's true that show(), etc. don't have the focus object as a parameter,
> you do have a three ways of tracking the focus object, via QWindow and
> QGuiApplication's signal as well as via setFocusObject in the input context
Hi,
While it's true that show(), etc. don't have the focus object as a parameter,
you do have a three ways of tracking the focus object, via QWindow and
QGuiApplication's signal as well as via setFocusObject in the input context
itself.
I'm missing something then, why is your virtual
Hi,
>
> === Protobuf ===
>
> * Need volunteers to write a Proof of Concept
> ** plugin to protoc?
IMHO flatbuffers (https://google.github.io/flatbuffers/) has quite a few
advantages over protocol buffers (one that I really like is that the only
dependency your app has is a single .h file,
On Tuesday 12 June 2018 00:41:38 Thiago Macieira wrote:
> On Monday, 11 June 2018 22:50:09 CEST Rafael Roquetto wrote:
> > Would it also make sense to explore msgpack? https://msgpack.org/
>
> No. Msgpack is the older version of CBOR, which we already have.
CBOR is IMHO better than Message
Hi Simon,
> But my initial guess is that this isn't an inherent design
> problem of the input method API.
Well, one problem is that the input context needs to know about the
current item, as it has to correspond with it. But QInputMethod::show/
commit/reset/update/hide do not transfer any
The proposed changes have been enacted.
--
Alex
> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Eike Ziller
> Sent: Wednesday, 23 May 2018 15:31
> To: Kai Koehne
> Cc: development@qt-project.org
> Subject: Re:
Hi,
I would imagine that there is a way for your virtual keyboard to not hide
itself if the focus object is transferred to an element of your virtual
keyboard itself. That said, I haven't your code, so I can't tell for sure. But
my initial guess is that this isn't an inherent design problem
Hi all,
when working on our virtual keyboard I had to realize that the design of
QInputMethod is inappropriate to achieve what we need:
a) the input method is tied to the item having the focus
We have a touch screen but also an special input device, that offers a
wheel to navigate along the
