Re: [Interest] qml <--> c++

2016-02-27 Thread Tony Rietwyk 
Hi Nicolas, 

 

I can see you left out Q_OBJECT on CustomWebView.  Not idea whether the rest 
will work or not to achieve your aim. 

 

Tony

 

 

From: Interest [mailto:interest-bounces+tony=rightsoft.com...@qt-project.org] 
On Behalf Of jagernico...@legtux.org
Sent: Sunday, 28 February 2016 3:16 PM
To: interest@qt-project.org
Subject: [Interest] qml <--> c++

 

Hi,

in my main.qml I have this code :

WebEngineView {
id: webview
url: "192.168.2.1"
anchors.fill: parent
onNewViewRequested: {
var w_ = crecreateObject()
request.openIn(appWin.w_)
}
}

when onNewViewRequested is called, I would like to open the url of the request 
in the the same WebEngineView, not creating a new WebEngine. So I was thinking 
to create some class who inherits of WebEngine.

I didn't found any class called WebEngine I can inherit, or I did not found the 
header... but I found QWebEngine, so I did this :

// in CustomWebView.h
#pragma once
#include 

class CustomWebView : public QWebEngineView
{
Q_PROPERTY(QString author READ author WRITE setAuthor NOTIFY authorChanged)

public:
CustomWebView(QWidget *parent);
CustomWebView();

};

I register the qml inside my main.cpp : 

qmlRegisterType("customWebView", 1, 0, "CustomWebView");

and in my main.qml I did some changes/add :

import CustomWebView 1.0

CustomWebView {
id: webview
url: "192.168.2.1"
anchors.fill: parent
//onNewViewRequested: {
//var w_ = crecreateObject()
//request.openIn(appWin.w_)
//}
}

but, when I compiled, I got the msg : Cannot assign to non-existent property 
"url"

obviously, I didi some mistake, but where ?

Regards,
Nicolas

 

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

[Interest] qml <--> c++

2016-02-27 Thread jagernicolas 
 

Hi,

in my main.qml I have this code :

 WebEngineView {
 id: webview
 url: "192.168.2.1"
 anchors.fill: parent
 onNewViewRequested: {
 var w_ = crecreateObject()
 request.openIn(appWin.w_)
 }
 }

when onNewViewRequested is called, I would like to open the url of the
request in the the same WebEngineView, not creating a new WebEngine. So
I was thinking to create some class who inherits of WebEngine.

I didn't found any class called WebEngine I can inherit, or I did not
found the header... but I found QWebEngine, so I did this :

// in CustomWebView.h
#pragma once
#include 

class CustomWebView : public QWebEngineView
{
 Q_PROPERTY(QString author READ author WRITE setAuthor NOTIFY
authorChanged)

public:
 CustomWebView(QWidget *parent);
 CustomWebView();

};

I register the qml inside my main.cpp : 

 qmlRegisterType("customWebView", 1, 0, "CustomWebView");

and in my main.qml I did some changes/add :

import CustomWebView 1.0

 CustomWebView {
 id: webview
 url: "192.168.2.1"
 anchors.fill: parent
// onNewViewRequested: {
// var w_ = crecreateObject()
// request.openIn(appWin.w_)
// }
 }

but, when I compiled, I got the msg : Cannot assign to non-existent
property "url"

obviously, I didi some mistake, but where ?

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

Re: [Interest] Emitting signal from QThread::run()

2016-02-27 Thread Sze Howe Koh 
On 28 February 2016 at 00:26, Alejandro Exojo  wrote:
>
> El Saturday 27 February 2016, Thiago Macieira escribió:
> > On sábado, 27 de fevereiro de 2016 11:45:50 PST Syam wrote:
> > > void MainWindow::someFunction()
> > > {
> > >
> > >MyThread *thread = new MyThread;
> > >connect(thread, SIGNAL(mySignal()), this, SLOT(myGuiSlot()),
> > >
> > > Qt::QueuedConnection);
> > >
> > >thread->start();
> > >
> > > }
> > >
> > >
> > > //
> > >
> > > Will the above code work fine? In myGuiSlot() I am typically manipulating
> > > some widgets - setting the text of a QLabel etc.
> >
> > Yes. The signal will be queued anyway.
>
> Will be queued without the explicit QueuedConnection? In other words, what
> does AutoConnection do here? run() is executed in another thread, but the
> QThread is in the same thread of MainWindow, right?

See http://doc.qt.io/qt-5/qt.html#ConnectionType-enum

"If the receiver lives in the thread that emits the signal,
Qt::DirectConnection is used. Otherwise, Qt::QueuedConnection is used.
The connection type is determined when the signal is emitted."

Qt checks to see which thread the signal is emitted from. Qt does not
check which thread the signal sender lives in.


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

Re: [Interest] moveToThread used in constructor to move "this"

2016-02-27 Thread Thiago Macieira 
On sábado, 27 de fevereiro de 2016 11:58:09 PST Lorenz Haas wrote:
> So it's all about the "unless..." part. Technically at the moment one
> is calling delete it's not guaranteed that there are no events. Inside
> the destructor, however, it is. So, assumed the documentation is
> right, would this special "delete foo;" use case in main() be safe?

If the object has timers or it tries to destroy QSocketNotifiers, it will also 
fail.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Interest] Emitting signal from QThread::run()

2016-02-27 Thread Thiago Macieira 
On sábado, 27 de fevereiro de 2016 17:26:32 PST Alejandro Exojo wrote:
> El Saturday 27 February 2016, Thiago Macieira escribió:
> > On sábado, 27 de fevereiro de 2016 11:45:50 PST Syam wrote:
> > > void MainWindow::someFunction()
> > > {
> > > 
> > >MyThread *thread = new MyThread;
> > >connect(thread, SIGNAL(mySignal()), this, SLOT(myGuiSlot()),
> > > 
> > > Qt::QueuedConnection);
> > > 
> > >thread->start();
> > > 
> > > }
> > > 
> > > 
> > > //
> > > 
> > > Will the above code work fine? In myGuiSlot() I am typically
> > > manipulating
> > > some widgets - setting the text of a QLabel etc.
> > 
> > Yes. The signal will be queued anyway.
> 
> Will be queued without the explicit QueuedConnection? In other words, what
> does AutoConnection do here? run() is executed in another thread, but the
> QThread is in the same thread of MainWindow, right?

It would have been queued with AutoConnection, yes.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Interest] QML Context2D createPattern not working when using an Image item

2016-02-27 Thread BOUCARD Olivier 
Hi,

On Qt 5.5.1 MinGW 32bit.


I'm making some test with the QML Canvas.
And I was trying to fill a rectangle with a PNG as pattern.
My Image is loaded using a QML Image item.
My drawing commands are in a separate Javascript file.
I access the image by adding an alias property to the Canvas pointing to the 
Image item.
I do this to simplify access in the Javascript file.
If I call drawImage using the alias it is working.
If I create a pattern using the same alias, set fillStyle and draw a rectangle, 
nothing is drawn.
If I create a pattern using the URL of the image then it works.

Is there something I missed or should I fill a bug report?

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

Re: [Interest] Emitting signal from QThread::run()

2016-02-27 Thread Alejandro Exojo 
El Saturday 27 February 2016, Thiago Macieira escribió:
> On sábado, 27 de fevereiro de 2016 11:45:50 PST Syam wrote:
> > void MainWindow::someFunction()
> > {
> > 
> >MyThread *thread = new MyThread;
> >connect(thread, SIGNAL(mySignal()), this, SLOT(myGuiSlot()),
> > 
> > Qt::QueuedConnection);
> > 
> >thread->start();
> > 
> > }
> > 
> > 
> > //
> > 
> > Will the above code work fine? In myGuiSlot() I am typically manipulating
> > some widgets - setting the text of a QLabel etc.
> 
> Yes. The signal will be queued anyway.

Will be queued without the explicit QueuedConnection? In other words, what 
does AutoConnection do here? run() is executed in another thread, but the 
QThread is in the same thread of MainWindow, right?

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] moveToThread used in constructor to move "this"

2016-02-27 Thread Lorenz Haas 
2016-02-24 18:23 GMT+01:00 Thiago Macieira :
> On quarta-feira, 24 de fevereiro de 2016 10:22:18 PST Lorenz Haas wrote:
>>Foo() : QObject(nullptr) {
>>   moveToThread(_thread);
>>   m_thread.start();
>>}
>>
>>~Foo() {
>>   m_thread.quit();
>>   m_thread.wait();
>>}
>
> This destructor is either never run or deadlocks.
>
> A QObject can only be destroyed in its thread of affinity. So the above is
> running in that m_thread thread, which means it hasn't exited. Waiting for it
> to exit will wait forever.

A follow up question of _pure academic_ nature:

Using deleteLater() on an instance of Foo is not working since the
thread deadlocks - just as you said. But how about using "delete foo;"
in main (regarding your comment "A QObject can only be destroyed in
its thread of affinity.")?

Using delete
a) the destructor would run in the GUI thread and therefor should be
fine to quit() and wait() the thread
b) after wait() the event loop of Foo is done and, suppose there is no
other concurrent access, it should be fine to delete Foo and its
QObject base class. The documentation states
http://doc.qt.io/qt-5/threads-qobject.html: "Calling delete on a
QObject from a thread other than the one that owns the object (or
accessing the object in other ways) is unsafe, unless you guarantee
that the object isn't processing events at that moment."

So it's all about the "unless..." part. Technically at the moment one
is calling delete it's not guaranteed that there are no events. Inside
the destructor, however, it is. So, assumed the documentation is
right, would this special "delete foo;" use case in main() be safe?

Once again, it's not for practical use, it's just out of technical
curiosity a colleague of mine came up with.


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

Re: [Interest] Emitting signal from QThread::run()

2016-02-27 Thread Thiago Macieira 
On sábado, 27 de fevereiro de 2016 11:45:50 PST Syam wrote:
> void MainWindow::someFunction()
> {
>MyThread *thread = new MyThread;
>connect(thread, SIGNAL(mySignal()), this, SLOT(myGuiSlot()),
> Qt::QueuedConnection);
>thread->start();
> }
> 
> 
> //
> 
> Will the above code work fine? In myGuiSlot() I am typically manipulating
> some widgets - setting the text of a QLabel etc.

Yes. The signal will be queued anyway.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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