[Development] QtCS 2018 - Qt Remote Objects session

[Stottlemyer, Brett (B.S.)]

I’ve posted notes from the session: https://wiki.qt.io/QtCS2018_RemoteObjects

Thanks to everyone who participated, and feel free to update if you see 
anything I missed.

Regards,
Brett
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 14 de junio de 2018 10:19:51 -03 Kevin Funk escribió:
> On Thursday, 7 June 2018 08:03:40 CEST Thiago Macieira wrote:
[snip] 
> Heya,
> 
> Patch for restoring qt5_use_modules() is here:
>   https://codereview.qt-project.org/#/c/232367/

yay, thanks a lot! I have read your comment on adding a deprecation warning on 
5.12: please go ahead (you might even add that in 5.11.2 if it ever gets to 
exist).

-- 
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
  Steve Jobs

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: unified data model API in QtCore

[Jason H]

There exists a need to store, load, and transmit strucured data in almost any application. Te topic at hand is the consideration of a generic format. Sure, you could create a relational database, but if you're nto trying to minimize writes and adapt your application to SQL, it's waste of effort. QDataStream is close, but it results in barely usable QVariantMap structure where modifications at the leaves have to be propigated to the root. There is a need for it to be 1. Easy to use:

   creation and modify: db["key"]["subkey"][i] =7;

   deletion: db["key"]["subkey"].delete(i)

   iteration for (const auto k: db["key"].keys())  db["key"][k]=7;

   navigation: parent()/children(), maybe `jq` compatible paths, xpath? (https://stedolan.github.io/jq/)

2. Serialize:

    db.save(filename)

    db.load(filename)

    db.stringify()

    db.parse(json)

3. Supported by Qt's model/view (Now I can tie UI Models to the db)

4. Emit events on CRUD  

   - no events, some specific events generating emits and their specific handlers, or all events to a global handler

   - now I can tie a UI elements to a spefific value in the db

   - now I can QNAM POST to another server or web front end (WebSocket) on change

 

Just a few thoughts for what I'd like. I'm not that much inerested in serialization speed, tbh. I'd probably use a strategy to copy the database at a consistent poitn in time (no handlers running) and save that in another thread to ensure consistency. So maybe there needs to be an API for that:

snapshot = db.beginSave().waitForIdle().copy() // wait blocks external sources, not internal ones since there may be an update cascade

db.resume();

QRunnable::run(snapshot, filename, Db::save);

 

Just my $0.02

 

 





...

In any case, what would be the added value of Qt providing new serialization formats & APIs, especially wrt exisiting header-only libraries (rapidjson, nlohmann/json for instance in the json world) which provide better performance AND compliance than Qt's  ?

...

 





 

 

---
Jean-Michaël Celerier

http://www.jcelerier.name



 

On Thu, Jun 14, 2018 at 3:13 PM, Thiago Macieira  wrote:

On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote:
> 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.

YAML, like CBOR, was designed with compatibility in mind. In fact, it's
designed so JSON-YAML conversion is lossless in both directions. So YAML makes
a lot of sense.

I don't know much about PB and FB, but from what I've seen it's meant to be a
serialisation format based on an IDL you describe. It's closer to QDataStream
than to JSON. From what I've seen, it makes no sense to merge those with the
other three than it does XML.

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

That was my original plan. The QCborValue backend can be reused for JSON as a
thin wrapper API. There's just a lot of copy & paste.

--
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 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] RFC: unified data model API in QtCore

[Thiago Macieira]

On Thursday, 14 June 2018 06:47:56 PDT Jean-Michaël Celerier wrote:
> > So YAML makes a lot of sense.
> 
> https://github.com/yaml/YAML2/wiki/People-Raging-About-YAML
> https://users.rust-lang.org/t/why-does-cargo-use-toml/3577/15
> 
> I would like to understand what all this discussion is about. What is the
> goal for Qt ?
> 
> a) allow developers using Qt to have a simple, human-readable (that's the
> n°1 feature my users always asked about save and file formats) and easy to
> write serialization method ?
> b) compatibility with existing formats, e.g. I want to communicate with a
> webservice which speaks JSON or whatever
> c) maximum performance for e.g. message passing between two processes ?

THIS discussion is none of those. This discussion is about the API we want to 
have for Qt for at least JSON and CBOR. We may want to add more formats and 
the one that comes to mind as the lowest hanging fruit is YAML.

You brought up TOML, which in turn brings to mind: should we merge with 
QSettings too?

> In any case, what would be the added value of Qt providing new
> serialization formats & APIs, especially wrt exisiting header-only
> libraries (rapidjson, nlohmann/json for instance in the json world) which
> provide better performance AND compliance than Qt's  ? (again, for json,
> https://github.com/miloyip/nativejson-benchmark)

That is not the discussion, but let me answer: people expect to have an API. 
>From the 41 libraries that were listed in there, can you list which ones 
support QString?

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

Re: [Development] RFC: unified data model API in QtCore

[Jean-Michaël Celerier]

> So YAML makes a lot of sense.

https://github.com/yaml/YAML2/wiki/People-Raging-About-YAML
https://users.rust-lang.org/t/why-does-cargo-use-toml/3577/15

I would like to understand what all this discussion is about. What is the
goal for Qt ?

a) allow developers using Qt to have a simple, human-readable (that's the
n°1 feature my users always asked about save and file formats) and easy to
write serialization method ?
b) compatibility with existing formats, e.g. I want to communicate with a
webservice which speaks JSON or whatever
c) maximum performance for e.g. message passing between two processes ?

In any case, every time I ever used JSON it is because it was necessary for
compatibility with existing interfaces - sometimes web APIs, sometimes
human beings who are used to reading JSON. I don't see this going away any
time soon...

In any case, what would be the added value of Qt providing new
serialization formats & APIs, especially wrt exisiting header-only
libraries (rapidjson, nlohmann/json for instance in the json world) which
provide better performance AND compliance than Qt's  ? (again, for json,
https://github.com/miloyip/nativejson-benchmark)

Best,


---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Jun 14, 2018 at 3:13 PM, Thiago Macieira 
wrote:

> On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote:
> > 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.
>
> YAML, like CBOR, was designed with compatibility in mind. In fact, it's
> designed so JSON-YAML conversion is lossless in both directions. So YAML
> makes
> a lot of sense.
>
> I don't know much about PB and FB, but from what I've seen it's meant to
> be a
> serialisation format based on an IDL you describe. It's closer to
> QDataStream
> than to JSON. From what I've seen, it makes no sense to merge those with
> the
> other three than it does XML.
>
> > > 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.
>
> That was my original plan. The QCborValue backend can be reused for JSON
> as a
> thin wrapper API. There's just a lot of copy & paste.
>
> --
> 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[Thiago Macieira]

On Thursday, 14 June 2018 06:19:51 PDT Kevin Funk wrote:
> Heya,
> 
> Patch for restoring qt5_use_modules() is here:
>   https://codereview.qt-project.org/#/c/232367/

Thanks, Kevin!

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

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[Kevin Funk]

On Thursday, 7 June 2018 08:03:40 CEST Thiago Macieira wrote:
> Commit 02ed1b36daebed5f3997bb676cf5e818c0db9d3c was
> 
> Remove CMake code for CMake < 3.1
> 
> This removes the following functions from Qt5CoreMacros:
> - qt5_use_modules(...)
> 
> Which follows 2013's d9ea4bb1441534cfb9253303ac258951dfcc4d9e
> 
> Mark qt5_use_modules as obsolete.
> 
> Forward-port of cb7f32f5b861fe115fa71f64500a5cbb0b643f1b (Mark
> qt4_use_modules and qt4_automoc as obsolete., 2013-07-04) from
> cmake.git.
> 
> But it appears that in the 5 years since we deprecated it, people have not
> stopped using it. Did we have to remove it? Or should we have kept
> compatibility until Qt 6?

Heya,

Patch for restoring qt5_use_modules() is here:
  https://codereview.qt-project.org/#/c/232367/

Regards,
Kevin

> Just look at the failures in
> https://build.opensuse.org/project/monitor/openSUSE:Factory?
> arch_x86_64=1=0=1_standard=1
> 
> The majority of them are caused by the Qt 5.11 update, a great number of
> which are the cmake update (the rest are indirect header dependency and are
> easy to fix).



signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: unified data model API in QtCore

[Thiago Macieira]

On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote:
> 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.

YAML, like CBOR, was designed with compatibility in mind. In fact, it's 
designed so JSON-YAML conversion is lossless in both directions. So YAML makes 
a lot of sense.

I don't know much about PB and FB, but from what I've seen it's meant to be a 
serialisation format based on an IDL you describe. It's closer to QDataStream 
than to JSON. From what I've seen, it makes no sense to merge those with the 
other three than it does XML.

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

That was my original plan. The QCborValue backend can be reused for JSON as a 
thin wrapper API. There's just a lot of copy & paste.

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

Re: [Development] Merge and Integration status report

[Simon Hausmann]

Yes, that is another issue. But before that qtbase issue started showing up, 
the same change to 5.11.1 that you're trying to integrated failed when running 
a test that launches a separate process of testing the debugging integration. 
So once the qtbase issue is resolved it's likely that you'll run into the 
declarative failure again.



Simon


From: Jani Heikkinen
Sent: Thursday, June 14, 2018 10:47:43 AM
To: Simon Hausmann; development@qt-project.org
Subject: Re: Merge and Integration status report

Actually at least 5.11.1 declarative integration failure is timeout in qtbase 
-> Linux QEMU (gcc-armv7) build. So the failure is different there (in case it 
helps anything)

br,
Jani

From: Development  on 
behalf of Simon Hausmann 
Sent: Thursday, June 14, 2018 10:32 AM
To: development@qt-project.org
Subject: Re: [Development] Merge and Integration status report

 Hi,


Thank you Liang for the report.


On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 
5.11.1 and dev branches right now.


Those who may have tried staging changes there may have noticed that they are 
failing in one of the tests that launch a separate process for testing the 
debugging integration, limited to Windows 10 (x86 and x86-64).


Until we've found the root cause or a suitable workaround, please don't stage 
changes to qtdeclarative.


I can't see any recent common changes to qtbase or declarative that apply to 
all _four_ branches, so I suspect this flaky issue was caused by something 
below those two modules.


I'll post an update here when we've figured it out (workaround or solution).


Simon


From: Development  on 
behalf of Liang Qi 
Sent: Thursday, June 14, 2018 9:18:32 AM
To: development@qt-project.org
Subject: [Development] Merge and Integration status report

Integrations

* qt5 dev integration failed from June 2, a submodule update without 
qtdeclarative was done on June. 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68666 
declarative_core::MappingManagerError::test_error() failed
* * * https://codereview.qt-project.org/#/c/222768 Simon is working on that 
since yesterday

* qt5 5.11 integration failed from June 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - 
can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it.
* * Issue: https://bugreports.qt.io/browse/QTBUG-68741 
tst_QQmlDebuggingEnabler::qmlscene() failed
___
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] Merge and Integration status report

[Jani Heikkinen]

Actually at least 5.11.1 declarative integration failure is timeout in qtbase 
-> Linux QEMU (gcc-armv7) build. So the failure is different there (in case it 
helps anything)

br,
Jani

From: Development  on 
behalf of Simon Hausmann 
Sent: Thursday, June 14, 2018 10:32 AM
To: development@qt-project.org
Subject: Re: [Development] Merge and Integration status report

 Hi,


Thank you Liang for the report.


On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 
5.11.1 and dev branches right now.


Those who may have tried staging changes there may have noticed that they are 
failing in one of the tests that launch a separate process for testing the 
debugging integration, limited to Windows 10 (x86 and x86-64).


Until we've found the root cause or a suitable workaround, please don't stage 
changes to qtdeclarative.


I can't see any recent common changes to qtbase or declarative that apply to 
all _four_ branches, so I suspect this flaky issue was caused by something 
below those two modules.


I'll post an update here when we've figured it out (workaround or solution).


Simon


From: Development  on 
behalf of Liang Qi 
Sent: Thursday, June 14, 2018 9:18:32 AM
To: development@qt-project.org
Subject: [Development] Merge and Integration status report

Integrations

* qt5 dev integration failed from June 2, a submodule update without 
qtdeclarative was done on June. 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68666 
declarative_core::MappingManagerError::test_error() failed
* * * https://codereview.qt-project.org/#/c/222768 Simon is working on that 
since yesterday

* qt5 5.11 integration failed from June 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - 
can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it.
* * Issue: https://bugreports.qt.io/browse/QTBUG-68741 
tst_QQmlDebuggingEnabler::qmlscene() failed
___
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] Merge and Integration status report

[Simon Hausmann]

 Hi,


Thank you Liang for the report.


On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 
5.11.1 and dev branches right now.


Those who may have tried staging changes there may have noticed that they are 
failing in one of the tests that launch a separate process for testing the 
debugging integration, limited to Windows 10 (x86 and x86-64).


Until we've found the root cause or a suitable workaround, please don't stage 
changes to qtdeclarative.


I can't see any recent common changes to qtbase or declarative that apply to 
all _four_ branches, so I suspect this flaky issue was caused by something 
below those two modules.


I'll post an update here when we've figured it out (workaround or solution).


Simon


From: Development  on 
behalf of Liang Qi 
Sent: Thursday, June 14, 2018 9:18:32 AM
To: development@qt-project.org
Subject: [Development] Merge and Integration status report

Integrations

* qt5 dev integration failed from June 2, a submodule update without 
qtdeclarative was done on June. 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68666 
declarative_core::MappingManagerError::test_error() failed
* * * https://codereview.qt-project.org/#/c/222768 Simon is working on that 
since yesterday

* qt5 5.11 integration failed from June 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - 
can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it.
* * Issue: https://bugreports.qt.io/browse/QTBUG-68741 
tst_QQmlDebuggingEnabler::qmlscene() failed
___
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] Merge and Integration status report

[Liang Qi]

Integrations

* qt5 dev integration failed from June 2, a submodule update without 
qtdeclarative was done on June. 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68666 
declarative_core::MappingManagerError::test_error() failed
* * * https://codereview.qt-project.org/#/c/222768 Simon is working on that 
since yesterday

* qt5 5.11 integration failed from June 9
* * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - 
can't find some headers
* * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, 
Oswald please help to review it.
* * Issue: https://bugreports.qt.io/browse/QTBUG-68741 
tst_QQmlDebuggingEnabler::qmlscene() failed
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: unified data model API in QtCore

[Lars Knoll]

> 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

[Uwe Rathmann]

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