Re: [Development] RFC: unified data model API in QtCore
> On 14 Jun 2018, at 02:08, Thiago Macieira wrote: > > 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 similar-looking > APIs, with the duplication of documentation that goes along with it. Other > languages parse serialised data into their own data structures which provide > a > generic access and modification API. > > This email is to start that discussion and answer these questions: > > a) should we have this API? > > b) if so, what would this API look like? > > c) if not, should we unify at least JSON and CBOR? > > c) either way, should remove QCborValue until we have it? > > The current "Qt native" data structure is the trio QVariant, QVariantList and > QVariantMap. It is what some early (pre-Qt5) JSON parsers used, as JSON data > can be losslessly converted to a handful of metatypes. And as long as only > those types were used, the conversion to JSON is also lossless. I guess we all agree that QVariant is not really a good API for this :) > > This API would also be the replacement of the JSON and CBOR parsers, for > which > we'd have a unified API, something like: > > QFoo json = QJson::fromJson(jcontent); > QFoo cbor = QCbor::fromCbor(ccontent); > qDebug() << QCbor::toDiagnosticFormat(json);// yes, json > > And here's why I am having problems with this proposal: what else? We know we > can have a common API for JSON and CBOR because I've done it (it's > QCborValue) > and because CBOR is designed to be compatible with JSON. But what about other > protocols? Are we trying to shoehorn a square peg in a round hole? Recreate > multidimensional hierarchical tables (a.k.a., QAbstractItemModel))? I agree that we should avoid something like QAIM. What we can (and IMO should) do is share the implementation of the data model between CBOR and JSON. > > For example, the next data model over would be XML. And we are indeed missing > a DOM structure for it since we deprecated QDomDocument. Can anyone see a > data > structure that works for both JSON/CBOR and generic XML? More importantly, > one > that is worthy of being Qt, with nice, intuitive API? I’d leave XML out of this. It is difficult to integrate, as it has so many special features (entities, CDATA and lot of other things) making it a rather complex specification. But there are a couple of other formats that might fit a more generic data model. Yaml comes to my mind as an example, protobuf and flatbuffers might also be possible to stream into such a structure with some additional schema verification. > > I'm skeptical. What do you think?f One option could also be that we have a common implementation, and then a very thin API wrapper for each of the formats on top that will enforce the format specific limitations and give you a fully typed API. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInputMethod woes
Hi Simon, > While it's true that show(), etc. don't have the focus object as a > parameter, you do have a three ways Yes, sure: show() is not the problem. ( We also have situations, where the virtual keyboard is started by pressing a button, while the input should go to some sort of label - but let's forget about them here ) > I'm missing something then, why is your virtual keyboard hidden... It isn't. > ... when the > focus object transitions from an element in the regular UI to an element > in your virtual keyboard? Our keyboard is a container item having the tabFence/focusProxy flags being enabled. It is shown on QInputMethod::show and automatically gets the focus. Automatically transferring the focus on hide/show of popups ( = items with tabFence/focusProxy ) is part of the qskinny framework. ( in case you are looking for ideas for Qt6: almost every EGLFS application needs some sort of replacement for what a window manager does with regular windows ) But anyway - the text input loses the focus and one of the buttons inside the virtual keyboard receives it: then the first thing that needs to managed is, that whenever the focus changes - f.e when the focus gets transferred to the virtual keyboard, or simply when navigating along the buttons inside the keyboard - the input context receives QInputMethod::commit() requests. -- But let's also have a look at QQuickTextInput: it automatically calls QInputMethod::show, when receiving the focus. This makes the focus tab chain almost unusable, as the virtual keyboard pops up, only when trying to navigate over a text input - always stealing the focus. Then when closing the virtual keybaord and the focus returns to the text input: it immediately reopens the virtual keyboard. Automatically calling QInputMethod::show can be avoided by disabling the focusOnPress ( = Qt::ClickFocus ) property, but what to do, when it is needed ? So without hacking QQuickTextInput ( = accessing private headers ) on the C++ side you can't get any proper focus management working. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] RFC: unified data model API in QtCore
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 similar-looking APIs, with the duplication of documentation that goes along with it. Other languages parse serialised data into their own data structures which provide a generic access and modification API. This email is to start that discussion and answer these questions: a) should we have this API? b) if so, what would this API look like? c) if not, should we unify at least JSON and CBOR? c) either way, should remove QCborValue until we have it? The current "Qt native" data structure is the trio QVariant, QVariantList and QVariantMap. It is what some early (pre-Qt5) JSON parsers used, as JSON data can be losslessly converted to a handful of metatypes. And as long as only those types were used, the conversion to JSON is also lossless. This API would also be the replacement of the JSON and CBOR parsers, for which we'd have a unified API, something like: QFoo json = QJson::fromJson(jcontent); QFoo cbor = QCbor::fromCbor(ccontent); qDebug() << QCbor::toDiagnosticFormat(json);// yes, json And here's why I am having problems with this proposal: what else? We know we can have a common API for JSON and CBOR because I've done it (it's QCborValue) and because CBOR is designed to be compatible with JSON. But what about other protocols? Are we trying to shoehorn a square peg in a round hole? Recreate multidimensional hierarchical tables (a.k.a., QAbstractItemModel))? For example, the next data model over would be XML. And we are indeed missing a DOM structure for it since we deprecated QDomDocument. Can anyone see a data structure that works for both JSON/CBOR and generic XML? More importantly, one that is worthy of being Qt, with nice, intuitive API? I'm skeptical. What do you think?f -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 3D Studio RC2 is available
Hi, We have released Qt 3D Studio 2.0 RC2 today. It is available as both commercial and open source versions from online and offline installers. Qt 3D Studio 2.0 has a whole new 3D engine built on top of Qt 3D, a new timeline built from ground up with Qt based on the new timeline code in upcoming Qt Design Studio. Also there are a lot of improvements to the designer user experience, interactions in the 3D edit view and visualisation of lights and cameras being most notable ones. And of course we have numerous bug fixes. For instructions on how to get started and install everything correctly, see Laszlo’s excellent blog on the subject here: http://blog.qt.io/blog/2018/05/18/get-started-qt-3d-studio-2-0-beta-1/ Regards, Pasi Keränen Senior Manager, 3D Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInputMethod woes
> 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 > itself. This is how we track the focus object on e.g. iOS, where we also reconfigure the keyboard to match the focus object, e.g. if it needs numbers only input. Or we hide the keyboard or show the keyboard when moving from/to a focus object that has IM enabled or not. Tor Arne > > I'm missing something then, why is your virtual keyboard hidden when the > focus object transitions from an element in the regular UI to an element in > your virtual keyboard? Hiding is usually connected to the acceptance of the > newly focused object with regards to IME enabling when issuing an IME query. > Are those elements perhaps missing the handling of QInputMethodEvent, the > querying kind in particular? > > Simon > From: Development > on behalf of Uwe Rathmann > Sent: Wednesday, June 13, 2018 11:09:46 AM > To: development@qt-project.org > Subject: Re: [Development] QInputMethod woes > > 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 information about the item > calling them. > > In case of show() all the context can do is to assume that the item > having the active focus is the one to correspond ( what actually is not > always correct in our application ) with. > > In case of all other calls the context has no chance to find out if the > caller was the item it is corresponding with - at least not, when the > active focus has moved somewhere else. > > And you find various situations in QQuickWindow or the controls, where > inputMethod calls are done from items not being the corresponding one. > > F.e. in QQuickWindowPrivate::setFocusInScope/clearFocusInScope > QInputMethod::commit() gets called, whenever the focus is changing. As > this is might be wrong all our context can do is to ignore these calls in > general. > > -- > > As we also implement our own type of controls ( in C++ ) I can work > around most of these issue with bypassing the QInputMethod API and > calling our context manually using a proprietary API, where I'm adding > the caller as parameter. > > But this is obviously no option for the average Qt user. > > Uwe > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInputMethod woes
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 keyboard hidden when the focus object transitions from an element in the regular UI to an element in your virtual keyboard? Hiding is usually connected to the acceptance of the newly focused object with regards to IME enabling when issuing an IME query. Are those elements perhaps missing the handling of QInputMethodEvent, the querying kind in particular? Simon From: Development on behalf of Uwe Rathmann Sent: Wednesday, June 13, 2018 11:09:46 AM To: development@qt-project.org Subject: Re: [Development] QInputMethod woes 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 information about the item calling them. In case of show() all the context can do is to assume that the item having the active focus is the one to correspond ( what actually is not always correct in our application ) with. In case of all other calls the context has no chance to find out if the caller was the item it is corresponding with - at least not, when the active focus has moved somewhere else. And you find various situations in QQuickWindow or the controls, where inputMethod calls are done from items not being the corresponding one. F.e. in QQuickWindowPrivate::setFocusInScope/clearFocusInScope QInputMethod::commit() gets called, whenever the focus is changing. As this is might be wrong all our context can do is to ignore these calls in general. -- As we also implement our own type of controls ( in C++ ) I can work around most of these issue with bypassing the QInputMethod API and calling our context manually using a proprietary API, where I'm adding the caller as parameter. But this is obviously no option for the average Qt user. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2018 - Serialisation session notes
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, which makes it very portable). Here https://github.com/bog-dan-ro/flatbuffers I have an old fork that adds Qt support to flatbuffers. The only disadvantage that I found is that the maintainer was a little bit difficult to work with :). Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2018 - Serialisation session notes
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 Pack, but I don't see it as "the older version of CBOR". Rather, a different community (which in my experience has a larger adoption rate because it came first). I don't think we need support for it on Qt, but people who need to interoperate with it, will need one of the existing libraries. -- Viking Software, Qt and C++ developers for hire http://www.vikingsoftware.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInputMethod woes
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 information about the item calling them. In case of show() all the context can do is to assume that the item having the active focus is the one to correspond ( what actually is not always correct in our application ) with. In case of all other calls the context has no chance to find out if the caller was the item it is corresponding with - at least not, when the active focus has moved somewhere else. And you find various situations in QQuickWindow or the controls, where inputMethod calls are done from items not being the corresponding one. F.e. in QQuickWindowPrivate::setFocusInScope/clearFocusInScope QInputMethod::commit() gets called, whenever the focus is changing. As this is might be wrong all our context can do is to ignore these calls in general. -- As we also implement our own type of controls ( in C++ ) I can work around most of these issue with bypassing the QInputMethod API and calling our context manually using a proprietary API, where I'm adding the caller as parameter. But this is obviously no option for the average Qt user. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing maintainership for Qt Creator modules
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: [Development] Changing maintainership for Qt Creator modules > > +1. > Both are the de-facto maintainers of that code nowadays :) > > > On 23. May 2018, at 15:23, Kai Koehne wrote: > > > > Hi, > > > > I haven't actively worked on Qt Creator since a while, and would therefore > > like > to step down as the maintainer for the Qt Creator modules I'm still listed > for in > https://wiki.qt.io/Maintainers: > > > > > > Debugging & Profiling / QML > > > > I propose Ulf Hermann as replacement. > > > > > > Project Management & Targets / QML > > > > I propose Thomas Hartmann as replacement. > > > > > > Regards > > > > Kai > > > > -- > > Kai Koehne, Senior Manager R&D | The Qt Company > > > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > > 144331 B > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.zil...@qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB > 144331 B > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInputMethod woes
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 of the input method API. Regarding support for multiple screens I agree that the singleton design is a problem. I don't know of an easy way to work around it and I agree that this sounds like something that is worth fixing (associating input methods with screens). In the event that that requires binary incompatible changes or (more likely) changing the input method API itself - which I would say is rather low level - then that would make it something worth changing together with Qt 6. Simon From: Development on behalf of Uwe Rathmann Sent: Wednesday, June 13, 2018 9:03:13 AM To: development@qt-project.org Subject: [Development] QInputMethod woes 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 focus tab chain and a few buttons like 'ok'. So the virtual keyboard is part of the focus tab chain and all its buttons need to be accessible with this input device. And here is where the implemented input method concept fails - as soon as navigating inside the virtual keyboard the initial input control loses the focus and the input method gets disconnected. b) multiple screens Our application runs on several screens, where it is possible to have several virtual keyboards - one per screen - at the same time. The singleton concept of QInputMethod does not support this at all. Maybe this is worth to be put on the list for Qt6 ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QInputMethod woes
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 focus tab chain and a few buttons like 'ok'. So the virtual keyboard is part of the focus tab chain and all its buttons need to be accessible with this input device. And here is where the implemented input method concept fails - as soon as navigating inside the virtual keyboard the initial input control loses the focus and the input method gets disconnected. b) multiple screens Our application runs on several screens, where it is possible to have several virtual keyboards - one per screen - at the same time. The singleton concept of QInputMethod does not support this at all. Maybe this is worth to be put on the list for Qt6 ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
