Re: [Development] Qt Quick emulation layer crashed (1:0)

[Hartmann Thomas]

Hi,


The Timer element is not officially supported in the designer.  The designer 
does show an error message, that you can ignore though.

There are work arrounds for your isse:


1) Use .ui.qml files and decouple the logic that requires the Timer from the 
pure form (see: http://doc.qt.io/qtcreator/creator-quick-ui-forms.html).

2) If you need a quick solution than you can move the Timer into a component 
(e.g. MyTimer). That does work.


We do not regularly test unsupported elements and documents containing those. 
We concetrate on the QML subset we support for ui.qml files and that we can 
guarantee to work.

We do accept bugreports for issues like yours and we will fix them, but our 
focus is on UI elements.


Kind Regards,

Thomas Hartmann



From: Development 
 on behalf 
of Matías Néstor Ares 
Sent: Tuesday, March 15, 2016 5:43 PM
To: 
Subject: [Development] Qt Quick emulation layer crashed (1:0)

Hello everybody!!!

I have been testing Qt5.6

of course Beta an RC releases have some bugs as expected.

But in all recent linux releases including the final 5.6.0 release the QML 
design view is completely unusable.

Even the most simple qml led to "Qt Quick emulation layer crashed (1:0)"

I have been working in complex QML layouts and the designer was never really as 
useful as expected. it is very buggy across all releases from it first 
appearance.

But now it can't handle even something as simple as this example:

import QtQuick 2.5
import QtQuick.Controls 1.4

ApplicationWindow {
id: applicationWindow1
visible: true
width: 640
height: 480
title: qsTr("Testing")

Timer{
id:testiTimer
interval: 1500; running: true; repeat: true
onTriggered: {
console.log("message")
}
}

Rectangle {
id: testRectangle1
width: 383
height: 86
color: "#c2c2c2"
}

}

This code runs ok but can't be edited in design mode because "Qt Quick 
emulation layer crashed (1:0)" shows up.

is there a workaround? or some alternative?

Regards


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

Re: [Development] new debugsupport module and API

[Hartmann Thomas]

Hi,

I guess using a TCP connection would still be possible, but not be the defaut 
anymore for local debugging/profiling?

Kind Regards,
Thomas Hartmann

From: development-bounces+thomas.hartmann=digia@qt-project.org 
[development-bounces+thomas.hartmann=digia@qt-project.org] on behalf of Ulf 
Hermann [ulf.herm...@digia.com]
Sent: 12 May 2014 11:48
To: development@qt-project.org
Subject: [Development] new debugsupport module and API

Hi,

we currently have several implementations of the QML debug protocol used
to transmit data between a debugger or profiler and the application
being debugged or profiled. I'm proposing a generalized debugsupport
module to address various issues with those. In particular:


1. Code duplication
---

We currently have implementations of QPacketProtocol in:
- qtdeclarative/src/plugins/qmltooling/shared/
- qtdeclarative/tools/qmlprofiler
- qtquick1/src/declarative/debugger
- qt-creator/src/libs/qmldebug

We have differently named but functionally largely identical
implementations of the qml debug client and connection in:
- qtdeclarative/tests/auto/qml/debugger/shared
- qtdeclarative/tools/qmlprofiler
- qtquick1/src/declarative/debugger
- qt-creator/src/libs/qmldebug

We also have 2 server implementations, in qtquick1 and qtdeclarative.
The debug clients and servers share a lot of functionality regarding
connection handling and notifying their plugins about various
conditions. Those plugins for servers and clients can share the same
base class as they all expose the same interface to the server or
client. Currently we have 6 of those base classes.


2. Missing flexibility
--

Currently a TCP connection is used for any kind of debugging or
profiling. This is potentially wasteful and dangerous as TCP has a
certain overhead and the protocol itself doesn't care about security.
Providing a connection over a QLocalSocket at least as an option seems
to be a good idea.

The debug server is currently tied into QtQml, even though it has
technically nothing to do with QML. It's a general purpose tool
for interacting with an application over a defined interface. It should
live in a more appropriate place so that we can use it in other
contexts if the need arises.


3. Messy implementation
---

Many of the client implementations are badly written, potentially leak
memory, don't properly handle errors, expose too many details of the
underlying connection and provide subtly different interfaces to their
plugins.

It's also a bad idea to specify the interface between the debug server
and client in terms of an arcane binary protocol full of magic numbers
and with a colorful history (e.g. the protocol version is unusable; we
practically never do service advertisement; in order to extend the
protocol you can only add things to the end of messages, but you can
never change any existing parts; service versions are transmitted as
floats). Hiding the mess behind a clean C++ interface will make it much
easier to work with and enables us to eventually replace the protocol
with something less crazy.


The following changes create a debugsupport module with public API in
qtbase:
https://codereview.qt-project.org/#change,85098
https://codereview.qt-project.org/#change,85099
https://codereview.qt-project.org/#change,85100
https://codereview.qt-project.org/#change,85101
https://codereview.qt-project.org/#change,85102
https://codereview.qt-project.org/#change,85103

I also have some WIP changes for qtdeclarative to use debugsupport:
https://codereview.qt-project.org/#change,84103
https://codereview.qt-project.org/#change,84527

And for QtCreator:
https://codereview.qt-project.org/#change,84526

QtQuick1 will get the same treatment.

--
Ulf Hermann, Software Engineer - Digia, Qt
___
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] Qt 5.3 qmltypes update

[Hartmann Thomas]

Hi,

please note that we had to hand edit some files to work around limitations of 
the code model.
Currently I am aware of the fact that we have to forward declare Window in 
the qmltypes file of controls.
So please if you update a qmltypes file check the history and if you see 
something weird add Fazwi or me as a reviewer.

Kind Regards,
Thomas Hartmann

From: development-bounces+thomas.hartmann=digia@qt-project.org 
[development-bounces+thomas.hartmann=digia@qt-project.org] on behalf of 
Alan Alpert [4163654...@gmail.com]
Sent: 01 May 2014 23:28
To: development
Subject: [Development] Qt 5.3 qmltypes update

If your module has QML types, and you provide a qmltypes file, you
still need to update those manually each release.

Until we have an automated tool for this (I started work on one in
5.2, but it doesn't work anymore), a manual inspection of the qmltypes
file diffs can also help identify any QML type revisioning errors (or
accidentally exposed members). I recommend you do this if your module
has QML types.

I've done it for qtdeclarative just now (apologies for being a bit
late in the release process), it resulted in two changes; one for
qtbase and one for qtdeclarative:

https://codereview.qt-project.org/#change,84465
https://codereview.qt-project.org/#change,84468

Mostly just people forgetting to revision new signals, but one lucky
guy got his code into 5.3 when he clearly wasn't expecting it to make
it until 5.4 ;) . Ideally when we have an automated process for
updating qmltypes, it can do some replacement logic to pick the minor
version for new features instead of people having to guess.

--
Alan Alpert
___
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] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Hartmann Thomas]

Hi,

 Can you elaborate a bit with an example what this means?

Some rough ideas were discussed here:

http://lists.qt-project.org/pipermail/development/2013-June/011572.html

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

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Hartmann Thomas]

Hi,

the original idea was to get rid of the need to write Java Script to change a 
state (state = newState) and find
a declarative way to change states. The rest then came naturally.

Kind Regards,
Thomas Hartmann

From: Hausmann Simon
Sent: 30 April 2014 11:38
To: Hartmann Thomas
Cc: development@qt-project.org; Alan Alpert
Subject: Re: [Development] Perceptions/Understandings of the QML language [was: 
Question about Qt's future]

On Wednesday 30. April 2014 11.11.39 Hartmann Thomas wrote:
 Hi,

  Can you elaborate a bit with an example what this means?

 Some rough ideas were discussed here:

 http://lists.qt-project.org/pipermail/development/2013-June/011572.html

Ahh, replacing arbitrarily complex when bindings?

That sounds like a good idea. Thanks for the explanation :)


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

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Hartmann Thomas]

Hi,

On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz apoen...@t-online.de wrote:
 I think at least three modifications are inavoidable: For one, things that
 could be written in a declarative way but which currently are only possible
 using JavaScript, a declarative way should be added. Second, it should be
 stressed in the documentation (including the examples), that using
 inline imperative code is naughty. This can be supported by e.g. the QML
 Designer refusing to operate on such files. People can still do that, but
 would be on their own. And finally, and that's also acting as a proof that
 the first two items actually have been done, the JavaScript dependency
 should be _optional_.

Can we turn this into action points we _all_ agree on?
My personal favorites are (In no strict order):

(1) Identify non declarative parts of Qt Quick and add declarative API (e.g. 
setting states)
(2) Document that inline Java Script and mixing declarative and imperative code 
in one file has its pitfalls in big projects and creates issues for tooling. 
Explain the difference between pure declarative QML and QMLJS and the impact on 
tooling.
(3) Document that accessing ids from other .qml files without any interface 
(just relying on the fact that they are in the context) creates hard to 
maintain QML code.
(4) Writing (more) QML(JS) static analyzers that can check/enforce a proper 
strict mode for QML.
(5) Write refactoring tools that help to clean up existing code.
(6) Fix/cleanup existing demos and examples.
(7) Investigate how we can improve the interplay of QML and C++. Especially in 
C++/backend heavy projects.

As a second step the actual work has to be done of course.

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

Re: [Development] Question about Qt's future

[Hartmann Thomas]

Hi,

while (at least for me) it is not really clear where exactly the boundary 
between declarative and functional programming lies, we could/should at least 
rule out control flow statements and anything with side effects in bindings.

The statement width: Math.floor(height) could be considered declarative 
(enough), if we limit the allowed functions to a well defined subset.

But currentlty one can do this: width: { Any imperative code one can imagine, 
including loops, while(true) and side effects.  } This clearly is not 
declarative anymore. 

Another issue with QML is that some parts of the API of Qt Quick are not 
accessible through a declarative API (e.g. setting a state). While this is not 
a problem in principle (since we could extend the API), it is a problem in 
practice. 
Until now nobody (including me) found the time to fix it.

From my point of view many of these problems are caused by the fact that Qt 
Quick allows very fast prototyping
(And Qt Quick is an excellent UI prototyping tool.), but is also used in real 
production code.
While certain features (Like inlining .js code everywhere all over the place 
and no clear split between declarative UI and logic) are nice for protoyping, 
they can become a burden in larger production code.

To give a concrete example: While things like width: Math.max(someId.width, 
someOtherId.width) + magicNumber
are nice to achieve certain complex layouts and to circumvent limitations of 
the declarative layout system, they create a huge maintenance burden, because 
this kind of code is hard to read and does not play nice with tooling.

The only solution I see is to create a well defined QML/QtQuick (sub)set that 
is more suitable for production code/larger projects. Such QML would be more 
rigid, enforce more structure on the developer and would be as declarative as 
possible. 
Such a QML dialect could forbid any inline js code. All Java Script could 
would be part of .js files. 

Another idea is to allow C++ companion objects, that would take the place of 
any Java Script code for people who prefer C++. A companion object would be a 
QObject paired with the QML object, that has access to the QML context. The 
QObject would then define a couple of signals/slots that can be used from QML 
as Java Script is used today.

Kind Regards,
Thomas Hartmann

From: development-bounces+thomas.hartmann=digia@qt-project.org 
[development-bounces+thomas.hartmann=digia@qt-project.org] on behalf of 
Thiago Macieira [thiago.macie...@intel.com]
Sent: 28 April 2014 02:34
To: development@qt-project.org
Subject: Re: [Development] Question about Qt's future

Em seg 28 abr 2014, às 00:55:12, André Pönitz escreveu:
 On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
  Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
   Having imperative code on the JS side is also the root of the rejection
   of
   QML for many C++ developers. If QML would have been just a improved .ui
   nobody would have complained.
 
  We'd end up with one of the problems of CSS which is that you can't do
  calculations in the bindings. I can't do
 
  width: 50% - 10em
 
  The moment you start adding some math, you need stuff like Math.random()
  and you end up again in JS.

 Not true. Some (basic) math fits the declarative needs, and would
 be toolable. Math.random() does obviously not fit the bill.

Math.floor() then.

--
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] Question about Qt's future

[Hartmann Thomas]

Hi,

yes, writting C++ inline in QML would be another tooling nightmare. Also what 
is the problem with:

MouseArea {
onClicked: companion.mouseAreaClicked();
}

If tooling creates the companion object for you (In a wizard) and code 
completion and code naviagtion (F2) works as expected?


Kind Regards,
Thomas Hartmann



From: Nils Jeisecke [njeise...@saltation.de]
Sent: 28 April 2014 11:00
To: Hartmann Thomas
Cc: development@qt-project.org
Subject: Re: [Development] Question about Qt's future

Hi,

 Another idea is to allow C++ companion objects, that would
 take the place of any Java Script code for people who
 prefer C++. A companion object would be a QObject
 paired with the QML object, that has access to the
 QML context. The QObject would then define a couple
 of signals/slots that can be used from QML as
 Java Script is used today.
I really like this idea. Maybe one could even write C++ code
directly in the QML file and let a preprocessor generate
a proper C++ class containing this code. So, no more JavaScript,
data conversion and garbage collection. Or just another tooling
nightmare?

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

Re: [Development] Question about Qt's future

[Hartmann Thomas]

Hi,

good point and this shows why it is actually no that easy to come up with a 
nice solution.

The most natural solution for me would be to just add the mouse property to the 
java script context
of the function call. The java script context would be a C++ argument.

slot: 
mouseAreaClicked(QJSContext context)
{
   context.get(mouse.x) 
}

But currently this is not more then a couple of wild ideas.

Kind Regards,
Thomas Hartmann

From: Nils Jeisecke [njeise...@saltation.de]
Sent: 28 April 2014 11:56
To: Hartmann Thomas
Cc: development@qt-project.org
Subject: Re: [Development] Question about Qt's future

 Also what is the problem with:

 MouseArea {
 onClicked: companion.mouseAreaClicked();
 }

Where is the event handler's argument (the one that's kind of
invisible in QML and requires you to read the documentation, I think
it's called mouse :-).

Could this be a function binding instead?

MouseArea {
 onClicked: companion.mouseAreaClicked;
}

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

Re: [Development] Question about Qt's future

[Hartmann Thomas]

Hi,

gluing together C++ and Java Script is currently not always that easy.
The solution I propose is the option to write C++ code in the exact same way 
you currently write Java Script code.
This means every QML context/component can have a C++ object attached to it 
that implements a set of methods
that are exposed to QML. The important part would be that C++ would have access 
to the QML context (e.g. context.get(someID.x). 

All of this is already possible, if we assume that we handle the context via 
QVariant function arguments and resolve it on the JS side 
(someObjectInTheContext.mouseAreaClicked(mouse.x)), but it requires quite a lot 
of boiler plate code and there is no canonical well documented way how to 
exactly do this. 
Also the setting of context objects is string based and quite hard to track for 
the code model (especially if there is more then one engine in the project) for 
auto completion and code navigation.

What problem does this sovle?

If there is a complex C++ backend there is no glue code needed anymore. There 
would be no need to expose types from C++ to QML anymore, since it would work 
the other way around. QML would expose its context to C++.
People could work in nearly the same way as they work with .ui files.  
Typically the QML context is not very complex and only consists of a couple of 
objects, signals and state variables (e.g. currentIndex of a ComboBox). 

Kind Regards,
Thomas Hartmann

From: development-bounces+thomas.hartmann=digia@qt-project.org 
[development-bounces+thomas.hartmann=digia@qt-project.org] on behalf of 
André Somers [an...@familiesomers.nl]
Sent: 28 April 2014 11:57
To: development@qt-project.org
Subject: Re: [Development] Question about Qt's future

Hartmann Thomas schreef op 28-4-2014 11:32:
 Hi,

 yes, writting C++ inline in QML would be another tooling nightmare. Also 
 what is the problem with:

 MouseArea {
  onClicked: companion.mouseAreaClicked();
 }

 If tooling creates the companion object for you (In a wizard) and code 
 completion and code naviagtion (F2) works as expected?


I'm not sure if I understand what you mean by a companion object. Why
exactly do we need another object in the mix? Where does it come from?
Where is exposed to the C++ side of things? What problem is it supposed
to solve exactly?

QML already allows you to specify signals. Would exposing these signals
on the C++ side through the object created by QQmlComponent::create not
be enough? You could then on the QML side bind the handler to signal on
the root object (directly or indirectly), and handle the signal on the
C++ side. Tooling-wise, I _guess_ these signals could be exposed for
code completion and the likes.

But... you can already do something like that. You can already expose a
custom QObject with slots to QML that you can use to bind your handlers
to. Sort of like a UI controller object.


André
___
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