Re: [Interest] Binding based on typeof doesn't work any more

2019-10-17 Thread Ulf Hermann
> But still: Why has the behavior been (apparently) changed at all in the 
> first place? Or is it a bug after all?

It does sound like a bug. Can you please open a bug report at 
https://bugreports.qt.io ? I would like to know

* What is the last version of Qt your example worked correctly with?

* What version of Qt broke it?

* What is the value of "typeof Controller" in the case where it should 
show the empty string and in the case where it should show the actual 
value for the good and for the bad version of Qt.

* What type is Controller.successfulSteps

* If Controller.successfulSteps is an integer, does the following work?
text: typeof Controller === "undefined" ? 0 : Controller.successfulSteps

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QML and sensitive data

2019-09-10 Thread Ulf Hermann
Hi,

> Just in case if someone will be looking for solution - I've managed to
> eliminate all the sensitive data from memory on closing particular QML
> screen without sacrificing existing architecture. The secret is pretty
> simple: just avoid situations when QString-s gets copied into JS
> strings:
> 
> 1. Do not use QJsonArray as the model for QML, use QVariantList as the
> replacement instead. At least because QVariantList of QVariants of
> QStrings allows an access to QString if required.
> 2. Use Quick Controls 2 because they are implemented in C++ and thus
> doesn't result in creation of JS strings
> 3. On destruction of Quick Controls pass properties like 'text',
> 'displayText' etc to C++ where const_cast and nullify
> implicitly-shared buffer.
> Bonus: QJsonDocument provides nice 'rawData' function allowing to
> cleanup its internals if required.

I can _not_ recommend this approach. The string may get copied 
internally in many places. Bindings may be evaluated as JavaScript, 
necessitating a JavaScript string representation. The visual 
representation of the string may be generated at some point, passing the 
string through layers of rendering code. The string has to be assembled 
from input somehow, potentially by re-allocating and expanding a buffer 
as you type. The old buffer will not be erased, and the input events may 
be allocated and deleted on the heap, without erasing them before 
deletion. You can _not_ be sure that the string is completely erased 
from memory after theses steps.

And obviously const_cast'ing and nullifying a string is not thread safe. 
If you are running a threaded render loop, for example, you may just 
have created a race condition.

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QML and sensitive data

2019-09-05 Thread Ulf Hermann
> Cheap hack #1: assign both fields new values once validated, say "*" 
> and force screen update before navigating away.

No. Strings are immutable in QML (and JavaScript). The old string will 
still be in memory at that point. And no, it's not a QString. 
const-casting and overwriting from C++ wouldn't do, even if it didn't crash.

Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Overriding list properties in QML at initialisation

2019-08-14 Thread Ulf Hermann
Hello,

> If I create a class with a QQmlListProperty and then initialise it with 
> an array in some QML file, then subclass the QML type in a second QML 
> file and try to override the array there, when creating an instance of 
> the child class, the list contains the arrays concatenated instead of 
> the overriding array.

That's the expected behavior of the default property, e.g. children in 
QQuickItem. Arguably, it should not extend to explicitly setting any 
other list properties.

> In the following example, I would expect the list to contain 2 elements 
> instead of 5. What are your thoughts? Should I fill a bug report and try 
> to provide a fix?

Yes, that would be nice. Keep in mind that the default property should 
still behave the old way, but only if you actually use it as default 
property. The details can be discussed in the report, though.

best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Changes to Javascript runtime in 5.12

2019-01-03 Thread Ulf Hermann
Hi René,

> In JS libs before 5.12, I've always used a closure approach to not
> leak a bunch of private variables onto the global module object. This
> results in a layout much like so:
 >
> (function(lib) {
>   ... closed vars can be declared here ...
> 
>   lib.bar = function() {
> return "baz";
>   };
> })(this);

You can still pass an empty object to your anonymous function and 
extract the interesting bits of that into the JS file's global scope 
afterwards. Or you can declare a number of vars outside the anonymous 
function and assign functions to them from inside. Both options are 
indeed a bit uglier, though.

This looks like a regression in Qt 5.12, but I will need to take a 
closer look at it. Did we ever document anything about the semantics of 
the "this" object in JavaScript libraries?

best regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QML Debug API

2018-11-09 Thread Ulf Hermann
Hi Nils,

> I have read that QML offers a binary debug protocol that is used by 
> several tools to to gain insights into QML applications. I read about 
> this interface here: http://doc.qt.io/qt-5/qtquick-debugging.html
> It is stated that: "The Qt QML module provides services for debugging, 
> inspecting, and profiling applications via a TCP port."

In fact you can also use a local socket or (with restrictions) the 
native debugger as connection mechanism.

> I'm planning to build my own tool on top of that API. I searched around 
> for the description and details about this protocol for a while but 
> couldn't find much beside the qtdeclarative git repository which seems 
> to contain the implementation.
> 
> Do I have to reverese engeneer the API from the source code or is there 
> some form of documentation that I wasn't able to find?

There is private API for interacting with the various debug services. 
Take a look at src/qmldebug in qtdeclarative. The code results in a 
static library called QtQmlDebug. You can either link against that (with 
the usual caveats of using private API), or you can use the code to 
figure out how the protocol works.

There is QQmlDebugConnection to establish a connection to the target 
application, QV4DebugClient for JavaScript debugging, 
QQmlEngineDebugClient and QQmlInspectorClient for QML debugging, 
QQmlProfilerClient for profiling, QQmlEngineControlClient for 
synchronizing the profiler in case of multiple QML engines, and 
QQmlDebugMessageClient to receive debug messages through the connection. 
I'm thinking about adding QQmlDebugProcess to QtQmlDebug, so that you 
get an easy way to start a process and directly connect to it. That 
class so far is in tests/auto/qml/debugger/shared in qtdeclarative.

If there is demand for this, I would consider making it public. It 
probably needs some more cleanup, but generally the client interfaces 
look good.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] qmlscene install problems

2018-07-24 Thread Ulf Hermann
On 07/23/2018 07:55 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> El lunes, 16 de julio de 2018 08:12:25 -03 Ulf Hermann escribió:
>> This thread has gone so far south, we need to add some corrections ...
> [snip] 
>> So, it turns out I have another qmake (and qmlscene) in
>> /usr/lib/x86_64-linux-gnu/qt5/bin/ which are explicitly the right ones, and
>> which I can invoke manually if I actually need them. Qt Creator autodetects
>> those.
> 
> Mind you this is a debian-specific patch:
> 
> <https://salsa.debian.org/qt-kde-team/qt/qtcreator/blob/master/debian/patches/
> always_autotect_qt_versions>

If I read that correctly, the patch takes care of updating system provided Qt 
versions when they are installed or uninstalled. The initial detection of "the" 
system-installed Qt Version should also work with stock Qt Creator, via 
"qtchooser -l". You may want to push a clean version of this patch upstream. 
Automatically adapting to system configuration changes seems desirable to me.

Ulf

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] qmlscene install problems (was: Interest Digest, Vol 82, Issue 5)

2018-07-16 Thread Ulf Hermann
This thread has gone so far south, we need to add some corrections ...

First things first: You probably don't need qmlscene. The only project type 
that currently needs qmlscene to be available is the "Qt Quick UI Prototype". 
Unless you are working with such projects, you can ignore the warning.

>>> I just installed Qt Creator 4.5.2 from kubuntu apt sources.
>>> It installed qmlscene + qt development files at the same time.
>>> I can see clearly there is a qmlscene executable right next to qmake in 
>>> the same directory: /usr/lib/qt5/bin
>>> How do I get rid of the "no qmlscene installed" warning?

This may not be the place where Qt Creator expects qmlscene on your system. For 
example, on my system I have a /usr/bin/qmlscene, which is not an actual 
qmlscene binary, but belongs to a package called "qtchooser". qtchooser wraps 
different Qt versions on demand. The same holds for qmake itself, actually. On 
my system, just calling /usr/bin/qmake results in an error, because qtchooser 
defaults to Qt4 and I purposely don't have a Qt4 environment installed. Qt 
Creator will actually query the qmake that belongs to your Qt for the binary 
locations, and it has some heuristics on which one that might be. For me that 
results in something like:

# /usr/lib/x86_64-linux-gnu/qt5/bin/qmake -query
[...]
QT_INSTALL_BINS:/usr/lib/x86_64-linux-gnu/qt5/bin
[...]

Qt Creator will list the results of that query in the Qt Version options in 
Build & Run settings (press "Details" there). You can check if there is a 
qmlscene in the path given there, and if not, search the package database for 
one.

So, it turns out I have another qmake (and qmlscene) in 
/usr/lib/x86_64-linux-gnu/qt5/bin/ which are explicitly the right ones, and 
which I can invoke manually if I actually need them. Qt Creator autodetects 
those. I could also configure qtchooser to use them.

>> I've been using Creator from distro repos for a while in the past, and 
>> quite often this would result in some weirdness or breakage. I recommend 
>> installing Creator using the online installer instead.

You can just install the package that contains the right qmlscene binary for 
your Qt version. Debian has a separate package called "qmlscene". I don't know 
how that works on Ubuntu. In fact the online installer won't get you very far, 
unless you are willing to also use a version of Qt obtained via the same online 
installer. This whole thing is a problem of your Qt version and indeed possibly 
of Ubuntu messing up the paths. It's probably not a problem of Qt Creator.

> 1) Some fool used qml to create the welcome screen thus first introducing the 
> problem. qml should never be used for anything.
> 2) The 12 year old boys who crow about being "maintainers" of packages do 
> little in the way of actual maintenance and testing. They simply remove 
> anything someone complains about or which doesn't compile.
> 3) Ubuntu doesn't test shit. They rely on the YABUs (Yet Another uBUntu) to 
> provide fixes for them
> 4) Virtual Machines tend to hose QtCreator, or at least historically did.
> https://bugreports.qt.io/browse/QTCREATORBUG-958> [...]

And none of that has anything to do with qmlscene being installed or not, or 
how Qt Creator deals with it. Also, the qmlscene utility and the QML language 
are two rather different things. The welcome screen (used to) be written in 
QML, but Qt Creator doesn't use qmlscene to run it. So, all of this rant is as 
misplaced as it is unnecessary. The only thing that may be remotely relevant is 
the comment about Ubuntu's testing practices, but the information we have here 
is far from being conclusive on this being an actual problem. The author should 
be sorry for wasting everybody's time.

best regards,
Ulf Hermann
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Interest Digest, Vol 79, Issue 19

2018-04-26 Thread Ulf Hermann
> When I said "most machines are little-endian", I was referring to machines Qt 
> runs on and, therefore, would use QDataStream. The fact that the default is 
> big endian is short-sighted. It should default to little-endian.

We could change the default. All it takes is a new QDataStream::Version, isn't 
it? (And whoever prefers big endian can then still setByteOrder() on the data 
stream).

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QT SCXML: How to access Event parameter from State?

2018-03-16 Thread Ulf Hermann
> In the example above, how would we get access to Event parameter for "state1" 
> and "state5"?

You can access the event currently being processed via the data model. The 
EcmaScript data model has a readonly property "_event" and the C++ data model 
has a method scxmlEvent(). The null data model doesn't handle events, so 
without a data model, you can't access them.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] ASSERT: "m_engines.contains(engine)" in file qqmlenginedebugservice.cpp, line 802 qqmlenginedebugservice.cpp: 802

2017-12-08 Thread Ulf Hermann

What needs to be done to get rid of this assertion (is it possible at
all or QmlDebugger is always expect single QQmlEngine? )


You can have multiple QML engines attached to the debugger, but the 
current assumption is indeed that they all live in the GUI thread. This 
can probably be fixed, but are you sure that you don't hit any other 
limitations with this? For example, the type loader also does 
interesting things with threads and locking.


br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] SCXML and datamodel sharing in Qt Quick and C++

2017-12-01 Thread Ulf Hermann
> 1. I use scxml compiler and expose compiled machine to Qt Quick.
> 2. I use ecmascript as datamodel type. I create data entries in *.scxml file.
> 3. I need to repeat those values on Qt Quick side and assign to 
> StateMachine.initialValues so that they will be reset everytime machine 
> starts - without it even when default values for data entries in scxml file 
> are set - they are not reset.
> 4. To change model entries (and the same evaluate transition conditions that 
> have those entries in cond attribute) I need to send custom, external event 
> from Qt Quick (let's call it DATAMODEL.CHANGE), which contains dictionary. In 
> scxml I handle that event by assigning all entries of that dictionary to  
> corresponding datamodel entries.

You cannot really stop and "deinitialize" a statemachine. If you set running to 
false, it is paused and will continue from the point where it stopped when you 
set it to true again. So, in order to reset the data model you have to destroy 
and recreate the state machine.

> Is it possible by any way to define model once and share it between scxml 
> state machine, Qt Quick, C++ side?
QScxmlStateMachine has a property "dataModel" which can be accessed from the 
outside and you can manipulate properties on that. However, the respective 
methods are not Q_INVOKABLE, so for QML you'll have to wrap that in some other 
type. The lack of proper QML API for this may be a bug. In any case, sending an 
event to the state machine is a cleaner way to do this, as otherwise the 
machine will not know that the value has changed and will not react to the 
change until some other event happens.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QML debugger doesn't work for big cmake-based project

2017-08-11 Thread Ulf Hermann
On 08/11/2017 05:01 PM, Alexander Ivash wrote:
> But then way don't I see 'waiting for connection... ' ? 

Because it only starts waiting for connections once a QML engine exists. Before 
that there is nothing to debug anyway.

> Also, If what you say is true, then is it possible to increase this timeout ?

No, but you can press "Retry" on the connection failure message box that Qt 
Creator gives you.


Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QML debugger doesn't work for big cmake-based project

2017-08-11 Thread Ulf Hermann
On 08/11/2017 04:48 PM, Alexander Ivash wrote:
> On launching debugger I see 'QML debugging is enabled. Only use this in a
> safe environment.' but don't see 'Waiting for connnection...', so it
> looks line debugger is not completely initialized. 

Does your application do anything complicated before creating the first QML 
engine? The line is printed and the debugger is initialized once the first QML 
engine gets created. If that takes forever, Qt Creator might assume that there 
is no QML engine and give up.

cheers,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Crash with Qt application that use OpenGL

2017-04-21 Thread Ulf Hermann

ps: i had a chat with a mozilla developer some time ago: they never use
desktop opengl on windows, but only use ANGLE with a fallback to
software rendering, if the application crashes on customer's machines.


You can force Qt to use Angle by setting the QT_OPENGL environment 
variable to QT_OPENGL=angle. Then detect if it crashes, by registering a 
signal handler or similar (sorry, Qt cannot do that for you). If it has 
crashed the last time set QT_OPENGL=software. There you have the same 
behavior.


See also http://doc.qt.io/qt-5/windows-requirements.html for more details.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] 2017

2017-01-03 Thread Ulf Hermann



Another alternative of course is to use some other client-server protocol such 
that only the “model” of MVC is on the server, and UI rendering instructions 
are sent across the network instead of actual rendered graphics.  For example 
load QML over the network and run it locally.  For some reason we aren’t 
putting much emphasis on that as a primary use case yet, but I wonder if 
anybody in the field is doing much of that?


It's called "The Web" and there are many reasons to hate it. However, one thing the 
relevant people in the field got somewhat right (IMO) is the level of coupling between the 
"model" and the rest of the application.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Again trouble with SCXML donedata

2017-01-03 Thread Ulf Hermann

Hello,


[...]

EventConnection {

stateMachine: p.stateMachine

events: ["done.state.Leave"]

onOccurred: {

console.log("done: " + event.name + " [" + event.data + "]")

}

}

[...]



done.state.* events are internal. You can expose them using this snippet of 
scxml:







It requires the ecmascript data model and knowledge of the possible parameters, though. Also, 
 is sent with the done.state event of the parent state, not the done.state event 
for the  itself. That is, you want to listen for done.state. 
here, not done.state.Leave.

(I'm just realizing that the ftpclient example that comes with 5.8 is actually 
invalid scxml. If it wasn't, it would be a great example for how to forward 
events. So, don't look at it until it's fixed.)

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] [QGV] Asynchronous painting of millions QGPathItem

2016-12-06 Thread Ulf Hermann

Hello,

I had a somewhat similar, but not quite the same problem when building the 
timeline view for the QML profiler in Qt Creator. It's currently usable with up 
to about 1 million events in the timeline and you can zoom and scroll it. There 
might be potential for further optimization. I used the Qt Quick SceneGraph API 
to directly work with OpenGL geometry. The scene graph nodes are built on 
demand and then cached and recycled when applicable. You can check out the 
result in the Qt Creator sources in src/libs/timeline.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] SCXML editor in QtCreator

2016-11-29 Thread Ulf Hermann

Hello Wolf,

Thanks for trying the SCXML editor. Your feedback is appreciated.


I have tried out the SCXML editor plugin for the QtCreator. My first
impression is very positive. The editor creates nicely looking state
chart diagrams. There are only two downsides I have found so far:

1. Events are currently not visible in the diagram.


The event names are shown as labels for the transitions they trigger. Can you 
elaborate a bit on what you expect?


2. As far as I see it there is currently no possibility to add UML-like 
comments.


You can add meta data to states. Right click on some state and select 
"Metadata". That allows you to add arbitrary text attributes. They don't 
interfere with the functionality of the state machine.

regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] SCXML Statemachine donedata event

2016-11-28 Thread Ulf Hermann

Connections|{|
||target|: stateMachine|
|onEventOccurred: {|
|console.|log|(event.name)|
|}|
|}|


From QML you should use the EventConnection QML type. About like this:

EventConnection {
stateMachine: stateMachine
events: ["done.state.*"] // or ["done.state.somespecificstate", 
"done.state.someotherstate", ...]
onOccurred: console.log(event.name)
}

From C++ you can do the following:

statemachine.connectToEvent("done.state", [](const QScxmlEvent ) {
// do something
});

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QT plugins memory footprint and the debugger

2016-11-10 Thread Ulf Hermann



Looking at the source of qt, the problem is identical(though it is protected 
against runaway exceptions). The MinGw debug plugins of qtquick are quite large 
and use the same mechanism to load plugins. If, as in my case, the 
initialization of the program allocates considerable memory ( but tbh, not 
excesively so, there is plenty left) QT (and by extension QT quick) can run 
into problems; in debug mode, using MinGw. This wasnt the case in 5.2 so I must 
assume that code of loading plugins was changed in between.


MinGW maps the debug symbols into memory when loading libraries, which on 32bit systems 
quickly eats up your address range. One trick that worked for me is compiling everything 
(including Qt) with "-separate-debug-info". This will put the debug symbols 
into separate files that aren't mapped at run time. The debugger will still read them.

br,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QJSEngine vs. (deprecated) QScriptEngine performance - old thing winning!

2016-10-12 Thread Ulf Hermann



QJSEngine does not cache the compilation results if you just pass in plain 
strings. I also don't think QScriptEngine can do this here (but I haven't 
checked). QScriptEngine might be clever enough to automatically use the 
interpreter rather than JIT-compiling such small expressions. You can set the 
QV4_FORCE_INTERPRETER environment variable to force QJSEngine to use the 
interpreter rather than the JIT.

In any case it's a waste to parse the expressions from strings over and over 
and to not use the JIT. If you care about performance, you should try to parse 
the expressions only once.


Uhm ... the secret here is that you keep a QScriptProgram as the m_expression 
of your label item, which is basically a JS function compiled for QScript. So, 
of course, if you take the source code from that and then recompile it for 
QJSEngine on every iteration it will be slower than if you evaluate it straight 
away in QScriptEngine. If you instead kept a QJSValue with the same expression 
written as a JS function, QJSEngine would probably be much faster as 
QScriptEngine would have to recompile on each iteration.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QJSEngine vs. (deprecated) QScriptEngine performance - old thing winning!

2016-10-12 Thread Ulf Hermann



The usage scenario fits my needs, that is the reason to evaluate exactly this 
way.

I mean - should the QScriptEngine be deprecated, the QQmlEngine/QJSEngine 
should also have ways to utilize some form of JIT/preparse. Even in the first 
pass where JIT cannot be effective (or when I parse just the text expression) 
QScriptEngine beats newer and more shiny QJSEngine a lot. That is confusing to 
me and my point - why is QJSEngine offered as replacement of QScriptEngine when 
it is so much slower?


QJSEngine does not cache the compilation results if you just pass in plain 
strings. I also don't think QScriptEngine can do this here (but I haven't 
checked). QScriptEngine might be clever enough to automatically use the 
interpreter rather than JIT-compiling such small expressions. You can set the 
QV4_FORCE_INTERPRETER environment variable to force QJSEngine to use the 
interpreter rather than the JIT.

In any case it's a waste to parse the expressions from strings over and over 
and to not use the JIT. If you care about performance, you should try to parse 
the expressions only once.

Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QJSEngine vs. (deprecated) QScriptEngine performance - old thing winning!

2016-10-12 Thread Ulf Hermann

QJSValue result = qmlEngine.evaluate(item.m_expression.sourceCode());


I guess you are mostly profiling the JIT compiling, not the actual evaluation. 
In order to get realistic results you should keep the compiled representation 
of the expression around, e.g. as a JS function. From the docs:


QJSValue fun = myEngine.evaluate("(function(a, b) { return a + b;})");

> QJSValueList args; args << 1 << 2;
>QJSValue threeAgain = fun.call(QJSValue(), args); regards,
Ulf

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] "Proper" Date Locale support?

2016-06-07 Thread Ulf Hermann



I'm working with localization of dates. There is a standard JS API:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString#Using_options

But QML defines it's own Date:
http://doc.qt.io/qt-5/qml-qtqml-date.html

The difference being the MDN refers to an "options" object, and Qt uses a 
format string. With the update to a newer V8 engine, will we get the options behavior?


The QML Date type extends the JavaScript Date object. So, the locales/options variant of 
toLocaleString() would have to be implemented in the JavaScript engine, which is not V8 
but our own "V4". Be aware that the QML Date's toLocaleString() method hides 
the JavaScript method of the same name in QML Date objects. So, in addition we'd have to 
somehow autodetect the arguments format when the QML method is called.

regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QtPlugins statically linked not loading

2015-06-01 Thread Ulf Hermann
Hi Nuno,

 This is the .pro
 [...]
  LIBS += 
 /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick.2/libqtquick2plugin.a
  LIBS += 
 /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Window.2/libwindowplugin.a
  LIBS += 
 /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Controls/libqtquickcontrolsplugin.a
 }

You probably have to add the following somewhere:

LIBS += /path/to/libqmldbg_tcp.a

Then you should be able to to link the final library or application also with 
QML debugging enabled. Mind that this way your application has the QML debug 
server built in and whenever you start it with the right arguments or call 
QQmlDebuggingEnabler::startTcpServer() it will open a debug port and accept 
connections from anywhere. With a dynamically linked Qt you have the option to 
delete the plugin in order to prevent this.

regards,

-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QtPlugins statically linked not loading

2015-06-01 Thread Ulf Hermann
On 06/01/2015 06:10 PM, Thiago Macieira wrote:
 On Monday 01 June 2015 15:01:14 Ulf Hermann wrote:
 You probably have to add the following somewhere:

 LIBS += /path/to/libqmldbg_tcp.a

 but like I said, he shouldn't have to. That's a bug in QtQml that it uses
 qmldbg_tcp without linking to it.

This is a static build. There is no dynamic linking. The only way to make this 
work would be to build the plugin into QtQml. Actually it used to do this, 
until fac14e459734936320003c3e593481c9cb6079e5 - which explicitly avoided it 
with the following reasoning:

 commit fac14e459734936320003c3e593481c9cb6079e5
 Author: Pasi Petäjäjärvi pasi.petajaja...@digia.com
 Date:   Fri Oct 24 11:31:38 2014 +0300

 Don't embded qmldbg_tcp plugin to libQt5Qml in static build

 Embedding qmldbg_tcp sources to libQt5Qml causes multipled
 definitions of QTcpServerConnection symbols with static
 build on Qt Quick 2 applications. Qmake can resolve
 dependencies to static plugins applications use, so no
 need to embed this to libQt5Qml.

 Change-Id: I18c5e44b9ac3de4ef8be29cc5944de3527566b3c
 Reviewed-by: Fawzi Mohamed fawzi.moha...@theqtcompany.com

Now, I really don't know what qmake magic he is referring to here and where the 
multiple definitions came from. Maybe qmake is supposed to automatically add 
libqmldbg_tcp.a to the linker command line.


-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QtPlugins statically linked not loading

2015-06-01 Thread Ulf Hermann
 macx:{
  CONFIG += lib_bundle shared
  QTPLUGIN += qcocoa *qmldbg_tcp qmldbg_tcp_qtdeclarative*
I guess this doesn't have any effect on static builds. I'm no qmake expert, 
though. Also, there is only one of them. It's called qmldbg_tcp.

  QMAKE_POST_LINK = mv -f $(TARGET) 
 $$PWD/../vstbuild/32/$$join(TARGET,,,.vst)/Contents/MacOS/$$TARGET
  OTHER_FILES += Info.plist
  LIBS += 
 /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick.2/libqtquick2plugin.a
  LIBS += 
 /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Window.2/libwindowplugin.a
  LIBS += 
 /Users/nsantos/Qt/5.4/clang_32_static/qml/QtQuick/Controls/libqtquickcontrolsplugin.a
Apparently you've put some important plugins here. You could try adding the 
qmldbg_tcp one here, too.

-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QtPlugins statically linked not loading

2015-06-01 Thread Ulf Hermann
 When I built Qt statically I had used this line:

 configure -prefix /Users/nsantos/Qt/5.4/clang_32_static -platform 
 macx-clang-32 -commercial -release -static -nomake examples -nomake tests 
 -opengl desktop -skip webkit -skip multimedia -D QT_QML_NO_DEBUGGER

 I had to use -DQT_QML_NO_DEBUGGER because there was an issue when linking a 
 project using QtQml:

 Undefined symbols for architecture i386:
   QTcpServerConnection::QTcpServerConnection(), referenced from:
   QQmlDebugServerThread::run() in libQt5Qml.a(qqmldebugserver.o)
 ld: symbol(s) not found for architecture i386

 Do you think there is a relation between these two problems?

This is exactly what I'm talking about. As you seem to specify all the plugins 
manually anyway, you may want to drop -DQT_QML_NO_DEBUGGER and specify the 
qmldbg_tcp plugin in the .pro file, as that contains the implementation of 
QTcpServerConnection. Unless, of course, you don't want to do any QML debugging 
and profiling. In that case you should stick to -DQT_QML_NO_DEBUGGER.

-- 
Ulf Hermann, Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: ulf.herm...@theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 
63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest