Re: [Interest] QML WebView modules

[Nibedit Dey]

Dear Sze-Howe,

I haven't worked much in Qt web modules. But below is my understanding.

With Qt 5.5 the Qt WebKit module is deprecated:(
https://wiki.qt.io/New-Features-in-Qt-5.5#Deprecated_Functionality)

QWebView uses WebKit as the backend.

QWebEngineView uses Chromium as the backend.

WebView with the *same name* has been defined in both *WebKit* and
*WebEngine*. Hence import statement varies.[I believe this is the source of
confusion ]

*import QtWebKit 3.0*
*import QtWebView 1.0*

In 5.8,
*import QtWebView 1.1*
QT += qml quick *webview*
This is useful on mobile platforms such as Android, iOS, and WinRT;
especially on iOS, where policy dictates that all web content is displayed
using the operating system's web view. [
http://doc.qt.io/qt-5/qtwebview-index.html ]

Regards,
Nibedit

On Wed, Apr 5, 2017 at 4:20 AM, Sze Howe Koh  wrote:

> On 4 April 2017 at 21:39, Nibedit Dey  wrote:
> >
> >
> > Hi Mark,
> >
> > Qt WebEngine is only supported on desktop platforms.Hence Linux is
> supported.
> > It's not supported on mobile platforms yet .So Qt 5.5.1 doesn't support.
> > Refer: https://doc.qt.io/archives/qt-5.5/qtmodules.html
> >
> > To use WebView module, in pro file add:
> > QT += webkit
> > greaterThan(QT_MAJOR_VERSION, 4):QT+=webkitwidgets
>
> The Qt WebView module is not related to WebKit.
>
> Unfortunately, there are two different things named "WebView" in Qt,
> which is very confusing:
>
> * http://doc.qt.io/archives/qt-5.5/qml-qtwebview-webview.html
> * http://doc.qt.io/archives/qt-5.5/qml-qtwebkit-webview.html
>
>
> > For WebEngine module add:
> > QT += webengine
> >
> > In both cases, Linux should be working.
> >
> > Regards,
> > Nibedit
> > .
> >
> >
> > -- Forwarded message --
> > From: Mark Tucker 
> > Date: Tue, Apr 4, 2017 at 3:56 PM
> > Subject: [Interest] QML WebView modules
> > To: "interest@qt-project.org" 
> >
> >
> > Hi,
> >
> >
> >
> > I'm currently trying to create a QML app that works on both a Linux
> platform and an Android platform. Due to the nature of my target platforms
> (embedded systems), I'm limited to Qt 5.5.1 and cannot upgrade.
> >
> > Note that my app is pure QML and I cannot write any C++ code to solve
> this.
> >
> > To get the app running on Android, I can put "import QtWebView 1.1" into
> my QML file imports, and then create a simple WebView component and set its
> URL and that works.
> >
> > That same import doesn't work for me on Linux, however. I can use either
> "import QtWebKit 3.0" or "import QtWebEngine 1.1" (with the latter,
> changing my WebView to a WebEngineView too) and I can then see a webview
> that works with no issues, but neither of those are available on my Android
> target (nor, from what I understand, will they ever be).
> >
> > So, is there a way I can get the QtWebView import working on Linux? I
> can't seem to figure out how to build it, or if it's even a valid option.
> >
> > If not, then I guess that means I'll need to have different QML for both
> Linux and Android…
>
> When Qt WebView first started as a Tech Preview in Qt 5.4, it only
> supported Android and iOS. These platforms were chosen specifically
> because Qt WebKit and Qt WebEngine can't run on them.
>
> In later releases, support for desktop platforms was added to Qt
> WebView, but I'm not exactly sure which version. Qt 5.5 might be too
> early.
>
>
> > Thanks in advance
> >
> > Mark
>
> Regards,
> Sze-Howe
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QListWidgetItem selection border too large

[Frank Rueter | OHUfx]

Ah, thanks Jake, that would explain it. I am using an earlier version.
The host software I tested this in uses 4.8.5 though and somehow the 
problem doesn't appear in their version.
I wonder if there is a way to workaround this bug (as it will have to 
work as a standalone rather than run inside the host app)?!


I will likely opt for a horizontal splitter which would avoid the 
problem anyway, but I'd rather know how to fix it if at all possible.


Cheers,
frank


On 04/05/2017 12:01 PM, Jake Petroules wrote:

Which version of Qt are you using? I believe this was fixed by 
https://codereview.qt-project.org/#/c/150307/ in Qt 5.6. See also 
https://bugreports.qt.io/browse/QTBUG-50645


On Apr 4, 2017, at 1:59 PM, Frank Rueter | OHUfx  wrote:

Hi,

I have two QListWidgets living in a QSplitter.
I need the items to be editable.
Some of the item labels are longer than the visible label.
When I edit one, it's selection border extends right across the splitter like 
this:


It seems that the selection box is as large as the longest item label in the 
list.
How can I control this so it stays within it's own splitter space?

When I open it in a host app that bundles it's own PySide (and has it's one 
style sheet for all widgets), this problem does not occur, so I'm hoping there 
is a simple solution here.

Attached is the sample code.

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


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

Re: [Interest] QListWidgetItem selection border too large

[Jake Petroules]

Which version of Qt are you using? I believe this was fixed by 
https://codereview.qt-project.org/#/c/150307/ in Qt 5.6. See also 
https://bugreports.qt.io/browse/QTBUG-50645

> On Apr 4, 2017, at 1:59 PM, Frank Rueter | OHUfx  wrote:
> 
> Hi,
> 
> I have two QListWidgets living in a QSplitter.
> I need the items to be editable.
> Some of the item labels are longer than the visible label.
> When I edit one, it's selection border extends right across the splitter like 
> this:
> 
> 
> It seems that the selection box is as large as the longest item label in the 
> list.
> How can I control this so it stays within it's own splitter space?
> 
> When I open it in a host app that bundles it's own PySide (and has it's one 
> style sheet for all widgets), this problem does not occur, so I'm hoping 
> there is a simple solution here.
> 
> Attached is the sample code.
> 
> Cheers,
> frank
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Interest] QML WebView modules

[Sze Howe Koh]

On 4 April 2017 at 21:39, Nibedit Dey  wrote:
>
>
> Hi Mark,
>
> Qt WebEngine is only supported on desktop platforms.Hence Linux is supported.
> It's not supported on mobile platforms yet .So Qt 5.5.1 doesn't support.
> Refer: https://doc.qt.io/archives/qt-5.5/qtmodules.html
>
> To use WebView module, in pro file add:
> QT += webkit
> greaterThan(QT_MAJOR_VERSION, 4):QT+=webkitwidgets

The Qt WebView module is not related to WebKit.

Unfortunately, there are two different things named "WebView" in Qt,
which is very confusing:

* http://doc.qt.io/archives/qt-5.5/qml-qtwebview-webview.html
* http://doc.qt.io/archives/qt-5.5/qml-qtwebkit-webview.html


> For WebEngine module add:
> QT += webengine
>
> In both cases, Linux should be working.
>
> Regards,
> Nibedit
> .
>
>
> -- Forwarded message --
> From: Mark Tucker 
> Date: Tue, Apr 4, 2017 at 3:56 PM
> Subject: [Interest] QML WebView modules
> To: "interest@qt-project.org" 
>
>
> Hi,
>
>
>
> I'm currently trying to create a QML app that works on both a Linux platform 
> and an Android platform. Due to the nature of my target platforms (embedded 
> systems), I'm limited to Qt 5.5.1 and cannot upgrade.
>
> Note that my app is pure QML and I cannot write any C++ code to solve this.
>
> To get the app running on Android, I can put "import QtWebView 1.1" into my 
> QML file imports, and then create a simple WebView component and set its URL 
> and that works.
>
> That same import doesn't work for me on Linux, however. I can use either 
> "import QtWebKit 3.0" or "import QtWebEngine 1.1" (with the latter, changing 
> my WebView to a WebEngineView too) and I can then see a webview that works 
> with no issues, but neither of those are available on my Android target (nor, 
> from what I understand, will they ever be).
>
> So, is there a way I can get the QtWebView import working on Linux? I can't 
> seem to figure out how to build it, or if it's even a valid option.
>
> If not, then I guess that means I'll need to have different QML for both 
> Linux and Android…

When Qt WebView first started as a Tech Preview in Qt 5.4, it only
supported Android and iOS. These platforms were chosen specifically
because Qt WebKit and Qt WebEngine can't run on them.

In later releases, support for desktop platforms was added to Qt
WebView, but I'm not exactly sure which version. Qt 5.5 might be too
early.


> Thanks in advance
>
> Mark

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

Re: [Interest] WebEngineView memory cache

[Allan Sandfeld Jensen]

On Tuesday 04 April 2017, Jani Tykka wrote:
> Hi,
> 
> WebEngineViews has possibility to set:
> profile.httpCacheType: WebEngineProfile.MemoryHttpCache
> 
> Even though memory cache is set I can see that WebCache directory is
> created and data written there. Is this a bug or do you think it works
> as expected?
> 
It what is written is http-cache, then yes that would be a bug. Though other 
things are cached or saved too, which might still be there with just http 
cache disabled.

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

[Interest] QListWidgetItem selection border too large

[Frank Rueter | OHUfx]

Hi,

I have two QListWidgets living in a QSplitter.
I need the items to be editable.
Some of the item labels are longer than the visible label.
When I edit one, it's selection border extends right across the splitter 
like this:



It seems that the selection box is as large as the longest item label in 
the list.

How can I control this so it stays within it's own splitter space?

When I open it in a host app that bundles it's own PySide (and has it's 
one style sheet for all widgets), this problem does not occur, so I'm 
hoping there is a simple solution here.


Attached is the sample code.

Cheers,
frank
#!/usr/bin/env python
import Analysis
from PySide import QtGui, QtCore

class FileAnalyserPanel(QtGui.QDialog):

def __init__(self, parent=None):
super(FileAnalyserPanel, self).__init__(parent)
self.path = QtCore.QDir.homePath()
self.buildUI()
self.connectSignals()

def buildUI(self):
'''Sets all the rewuired layouts and widgets'''
# layouts
mainLayout = QtGui.QVBoxLayout()
self.setLayout(mainLayout)
topLayout = QtGui.QHBoxLayout()
middleLayout1 = QtGui.QHBoxLayout()
middleLayout1.setSizeConstraint(QtGui.QLayout.SetFixedSize)
middleLayout2 = QtGui.QHBoxLayout()
middleLayout2.setSizeConstraint(QtGui.QLayout.SetFixedSize)
bottomLayout = QtGui.QHBoxLayout()

# widgets
pathLabel = QtGui.QLabel('root path')
self.pathWidget = QtGui.QLabel()
self.pathWidget.setFrameStyle(QtGui.QFrame.StyledPanel|
  QtGui.QFrame.Sunken)
self.pathBtn = QtGui.QPushButton('Set Path...')
splitterWidget = QtGui.QSplitter()
self.fileListWidgetTotal = QtGui.QListWidget()
self.fileListWidgetAccepted = QtGui.QListWidget()
self.fileListWidgetRejected = QtGui.QListWidget()
splitterWidget.addWidget(self.fileListWidgetAccepted)
splitterWidget.addWidget(self.fileListWidgetRejected)

labelAccepted = QtGui.QLabel('Accepted')
labelAccepted.setSizePolicy(QtGui.QSizePolicy.Policy.Expanding, QtGui.QSizePolicy.Policy.Fixed)
labelRejected = QtGui.QLabel('Rejected')
labelRejected.setSizePolicy(QtGui.QSizePolicy.Policy.Expanding, QtGui.QSizePolicy.Policy.Fixed)
self.counterAccepted = QtGui.QLCDNumber()
self.counterAccepted.setSegmentStyle(QtGui.QLCDNumber.Flat)
self.counterAccepted.setSizePolicy(QtGui.QSizePolicy.Policy.Expanding, QtGui.QSizePolicy.Policy.Fixed)
self.counterRejected = QtGui.QLCDNumber()
self.counterRejected.setSegmentStyle(QtGui.QLCDNumber.Flat)
self.counterRejected.setSizePolicy(QtGui.QSizePolicy.Policy.Expanding, QtGui.QSizePolicy.Policy.Fixed)

# add widgets to layouts
topLayout.addWidget(pathLabel)
topLayout.addWidget(self.pathWidget, True)
topLayout.addWidget(self.pathBtn)
topLayout.addWidget(splitterWidget)
middleLayout1.addWidget(labelAccepted)
middleLayout1.addWidget(labelRejected)
middleLayout2.addWidget(self.counterAccepted)
middleLayout2.addWidget(self.counterRejected)
mainLayout.addLayout(topLayout)
mainLayout.addLayout(middleLayout1)
mainLayout.addWidget(splitterWidget)
mainLayout.addLayout(middleLayout2)
mainLayout.addLayout(bottomLayout)

def connectSignals(self):
self.pathBtn.clicked.connect(self.setPath)

def setPath(self):
#self.path = QtGui.QFileDialog.getExistingDirectory(self,
  #'Choose Path to analyse',
  #self.path)
self.pathWidget.setText(self.path)
listOfStuff = ['a'*100, 'b'*50, 'c'*20]
for f in listOfStuff:
item = QtGui.QListWidgetItem(f)
item.setFlags(item.flags() | QtCore.Qt.ItemIsEditable)
self.fileListWidgetAccepted.addItem(item)

if __name__ == '__main__':
import sys

app = QtGui.QApplication(sys.argv)
panel = FileAnalyserPanel()
panel.show()
panel.raise_()
sys.exit(app.exec_())
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] [Qt Connectivity] Bluetooth state is not a HostPoweredOff on Android when turning it off

[Oleg Evseev]

Hi,

I'm working with bluetooth on android. Handling bluetoothLocalDevice
hostModeStateChanged signal I get HostConnectable on one tablet (Android
5.1) and HostDiscoverable on another phone (Android 4.4.4) when I *turn off*
(!) bluetooth in system.
And no signals when I turn bluetooth on in system (and sometimes for
turning on too).

As I see in qt connectivity source code this status is based on android
scan mode and constants are correct:

switch (scanMode) {
case 20: // BluetoothAdapter.SCAN_MODE_NONE
return HostPoweredOff;
case 21: // BluetoothAdapter.SCAN_MODE_CONNECTABLE
return HostConnectable;
case 23: // BluetoothAdapter.SCAN_MODE_CONNECTABLE_DISCOVERABLE
return HostDiscoverable;

So it seems to be an android bug, but I haven't found any relevant problems
with android, so I wonder may this be an qt bug?

Thanks in advance for help.

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

Re: [Interest] QPrintPreviewWidget

[Dan Allen]

No problem. Thanks Roland.


On 04/04/17 18:32, Roland Hughes wrote:

Not ignoring your question Bill, but this response answered it better.

There is always __something__ which gets in the way. Ultimately you 
end up needing an object which can only exist in the primary thread 
due to the tight coupling of that thread to the underlying windowing 
system and that object being "GUI" instead of data.



On 04/04/2017 12:00 PM, interest-requ...@qt-project.org wrote:

I do not think that is an issue.
I think you can paint to a QImage in a non-GUI thread, because
a QIMage is a non-GUI object, unlike a QPixmap which is (or at least
was historically) a "GUI" object.

The term GUI (in this conversation and in my understanding)
is generally when you interact with the underlying window system to
create and use Windows which appear on the screen.

Yes, the QPainter class lives in the QtGUI module, but I do not
believe it's use is restricted to the main thread. On Linux and
in the past, interaction with the X11 server was limited to the main
thread. That is why use of QPixmap was limited to the main thread.
That is why use of on screen Windows was limited to the main thread.

  From the QPixmap doc:

  "...pixel data in a pixmap is internal and is managed
   by the underlying window system."

So (at least in the past) when you draw on a QPixmap, instructions
are being sent to the "underlying window system" and (in the past)
that was across a network connection to the X11 server.

How any of this has changed with the introduction
of QPA (Qt Platform Abstraction) I do not know.





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

Re: [Interest] QPrintPreviewWidget

[Roland Hughes]

Not ignoring your question Bill, but this response answered it better.

There is always __something__ which gets in the way. Ultimately you end 
up needing an object which can only exist in the primary thread due to 
the tight coupling of that thread to the underlying windowing system and 
that object being "GUI" instead of data.



On 04/04/2017 12:00 PM, interest-requ...@qt-project.org wrote:

I do not think that is an issue.
I think you can paint to a QImage in a non-GUI thread, because
a QIMage is a non-GUI object, unlike a QPixmap which is (or at least
was historically) a "GUI" object.

The term GUI (in this conversation and in my understanding)
is generally when you interact with the underlying window system to
create and use Windows which appear on the screen.

Yes, the QPainter class lives in the QtGUI module, but I do not
believe it's use is restricted to the main thread. On Linux and
in the past, interaction with the X11 server was limited to the main
thread. That is why use of QPixmap was limited to the main thread.
That is why use of on screen Windows was limited to the main thread.

  From the QPixmap doc:

  "...pixel data in a pixmap is internal and is managed
   by the underlying window system."

So (at least in the past) when you draw on a QPixmap, instructions
are being sent to the "underlying window system" and (in the past)
that was across a network connection to the X11 server.

How any of this has changed with the introduction
of QPA (Qt Platform Abstraction) I do not know.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/

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

Re: [Interest] QPrintPreviewWidget

[Dan Allen]

Thanks for your help Bill.


On 04/04/17 17:56, william.croc...@analog.com wrote:

On 04/04/2017 11:52 AM, Dan Allen wrote:

Hi Bill,

What you've listed below is pretty much how my printing mechanism 
works.  This

works perfectly and I'm happy with it.

I'm still a little confused as to why the preview can't operate in 
the same
way.  If another thread paints into a QImage and then informs the 
dialog using a
signal such that the GUI thread can then display it on the screen, 
why is this

an issue?


I do not think that is an issue.
I think you can paint to a QImage in a non-GUI thread, because
a QIMage is a non-GUI object, unlike a QPixmap which is (or at least
was historically) a "GUI" object.

The term GUI (in this conversation and in my understanding)
is generally when you interact with the underlying window system to
create and use Windows which appear on the screen.

Yes, the QPainter class lives in the QtGUI module, but I do not
believe it's use is restricted to the main thread. On Linux and
in the past, interaction with the X11 server was limited to the main
thread. That is why use of QPixmap was limited to the main thread.
That is why use of on screen Windows was limited to the main thread.

From the QPixmap doc:

"...pixel data in a pixmap is internal and is managed
 by the underlying window system."

So (at least in the past) when you draw on a QPixmap, instructions
are being sent to the "underlying window system" and (in the past)
that was across a network connection to the X11 server.

How any of this has changed with the introduction
of QPA (Qt Platform Abstraction) I do not know.

Bill


Why does the GUI thread have to do the time consuming task?  The Qt
documentation for QImage states "When using QPainter on a QImage, the 
painting

can be performed in another thread than the current GUI thread."


Yes. That is my understanding too, as stated above.



Thanks,

Dan Allen.


On 03/04/17 14:49, william.croc...@analog.com wrote:

On 04/01/2017 09:48 AM, Dan Allen wrote:

Hi Bill,

I agree, however when the print is quite complex it makes the GUI very
unresponsive.

Painting into an off screen image is not GUI related. The print 
preview could
show something like "Generating Preview" while a background thread 
generates it
and then show it when it's ready for example. This would prevent 
the GUI from
seeming unresponsive to the user. I wasn't sure if there was a 
current method to

do something like this.



Yes. We agree that the actual printing is non GUI, but if you want
to show a print preview or progress meter, that is GUI and needs
to stay in the main thread.

So, something like:
- Create a progress meter dialog.
- Start your printing in a sub thread.
- The main thread waits, perhaps in a sub-QEventLoop, servicing events.
- After a few seconds, if printing has not completed, show the dialog.
- The sub-event loop monitors the printing process with a thread safe
  communication mechanism, like signals and slots.
- When the printing completes, close the dialog.
- Exit your sub-event loop.


Thanks,

Dan Allen.


On 01/04/17 13:43, william.croc...@analog.com wrote:

On 04/01/2017 03:41 AM, Dan Allen wrote:

Hi,

Could anyone tell me if it's possible to paint into a 
QPrintPreviewWidget in

another thread, and if so, how?

I have created a class to perform printing and this runs in 
another thread.
When used for printing it works fine.  However when used for the 
print

preview,
nothing is shown unless I force the signal to either 
Qt::DirectConnection

(i.e.
use the GUI thread) or Qt ::BlockingQueuedConnection (i.e. block 
the GUI

thread).


Dan:

Conventional wisdom, if not the rule of law, states that all GUI 
activity

should be done from the main thread. You may just be experiencing
the Qt library enforcing this rule.

Bill


Thanks,

Dan Allen.


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




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



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




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



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




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



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

Re: [Interest] QPrintPreviewWidget

[william.croc...@analog.com]

On 04/04/2017 11:52 AM, Dan Allen wrote:

Hi Bill,

What you've listed below is pretty much how my printing mechanism works.  This
works perfectly and I'm happy with it.

I'm still a little confused as to why the preview can't operate in the same
way.  If another thread paints into a QImage and then informs the dialog using a
signal such that the GUI thread can then display it on the screen, why is this
an issue?


I do not think that is an issue.
I think you can paint to a QImage in a non-GUI thread, because
a QIMage is a non-GUI object, unlike a QPixmap which is (or at least
was historically) a "GUI" object.

The term GUI (in this conversation and in my understanding)
is generally when you interact with the underlying window system to
create and use Windows which appear on the screen.

Yes, the QPainter class lives in the QtGUI module, but I do not
believe it's use is restricted to the main thread. On Linux and
in the past, interaction with the X11 server was limited to the main
thread. That is why use of QPixmap was limited to the main thread.
That is why use of on screen Windows was limited to the main thread.

From the QPixmap doc:

"...pixel data in a pixmap is internal and is managed
 by the underlying window system."

So (at least in the past) when you draw on a QPixmap, instructions
are being sent to the "underlying window system" and (in the past)
that was across a network connection to the X11 server.

How any of this has changed with the introduction
of QPA (Qt Platform Abstraction) I do not know.

Bill


Why does the GUI thread have to do the time consuming task?  The Qt
documentation for QImage states "When using QPainter on a QImage, the painting
can be performed in another thread than the current GUI thread."


Yes. That is my understanding too, as stated above.



Thanks,

Dan Allen.


On 03/04/17 14:49, william.croc...@analog.com wrote:

On 04/01/2017 09:48 AM, Dan Allen wrote:

Hi Bill,

I agree, however when the print is quite complex it makes the GUI very
unresponsive.

Painting into an off screen image is not GUI related. The print preview could
show something like "Generating Preview" while a background thread generates it
and then show it when it's ready for example. This would prevent the GUI from
seeming unresponsive to the user. I wasn't sure if there was a current method to
do something like this.



Yes. We agree that the actual printing is non GUI, but if you want
to show a print preview or progress meter, that is GUI and needs
to stay in the main thread.

So, something like:
- Create a progress meter dialog.
- Start your printing in a sub thread.
- The main thread waits, perhaps in a sub-QEventLoop, servicing events.
- After a few seconds, if printing has not completed, show the dialog.
- The sub-event loop monitors the printing process with a thread safe
  communication mechanism, like signals and slots.
- When the printing completes, close the dialog.
- Exit your sub-event loop.


Thanks,

Dan Allen.


On 01/04/17 13:43, william.croc...@analog.com wrote:

On 04/01/2017 03:41 AM, Dan Allen wrote:

Hi,

Could anyone tell me if it's possible to paint into a QPrintPreviewWidget in
another thread, and if so, how?

I have created a class to perform printing and this runs in another thread.
When used for printing it works fine.  However when used for the print
preview,
nothing is shown unless I force the signal to either Qt::DirectConnection
(i.e.
use the GUI thread) or Qt ::BlockingQueuedConnection (i.e. block the GUI
thread).


Dan:

Conventional wisdom, if not the rule of law, states that all GUI activity
should be done from the main thread. You may just be experiencing
the Qt library enforcing this rule.

Bill


Thanks,

Dan Allen.


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




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



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




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



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




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

Re: [Interest] QPrintPreviewWidget

[Dan Allen]

Hi Roland,

Not 100% sure what you mean in the first part.  Are you also saying I 
shouldn't use a another thread?


Thanks,

Dan Allen.


On 04/04/17 12:24, Roland Hughes wrote:


You know, "painting into an off screen image is not GUI related" 
__should__ be true. Haven't tried it since 4.8.x, but it certainly 
wasn't true back then. Desperately wanted to thread off the generating 
of many pixmaps which would be later BLITted onto the touch screen as 
needed by application. Nope nope nope nope. (Please, don't suggest 
alternatives to pre-loading. Embedded device, single core, no GPU 
trying to achieve 10 days of run-time battery life. Last I heard, we 
did it and we had a responsive GUI touchscreen.)


This "all things GUI in primary thread" philosophy has an awful lot of 
real world fallout, especially in the embedded world where RAM is fast 
but hardened storage is slooow. It also leads to some pretty 
horrible database interfaces, in particular when using 
spreadsheet/table models to scroll through networked/remote databases 
with millions of records where the connection could require several 
seconds to respond. Yes, I've had to do some hacks to thread that 
stuff off, but the primary examples floating around out there show it 
all running in the GUI thread.


Roland


On 04/04/2017 01:47 AM, interest-requ...@qt-project.org wrote:

On 04/01/2017 09:48 AM, Dan Allen wrote:

Hi Bill,

I agree, however when the print is quite complex it makes the GUI very
unresponsive.

Painting into an off screen image is not GUI related. The print preview could
show something like "Generating Preview" while a background thread generates it
and then show it when it's ready for example. This would prevent the GUI from
seeming unresponsive to the user. I wasn't sure if there was a current method to
do something like this.


Yes. We agree that the actual printing is non GUI, but if you want
to show a print preview or progress meter, that is GUI and needs
to stay in the main thread.

So, something like:
- Create a progress meter dialog.
- Start your printing in a sub thread.
- The main thread waits, perhaps in a sub-QEventLoop, servicing events.
- After a few seconds, if printing has not completed, show the dialog.
- The sub-event loop monitors the printing process with a thread safe
communication mechanism, like signals and slots.
- When the printing completes, close the dialog.
- Exit your sub-event loop.


Thanks,

Dan Allen.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/


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


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

Re: [Interest] QPrintPreviewWidget

[Dan Allen]

Hi Bill,

What you've listed below is pretty much how my printing mechanism 
works.  This works perfectly and I'm happy with it.


I'm still a little confused as to why the preview can't operate in the 
same way.  If another thread paints into a QImage and then informs the 
dialog using a signal such that the GUI thread can then display it on 
the screen, why is this an issue?  Why does the GUI thread have to do 
the time consuming task?  The Qt documentation for QImage states "When 
using QPainter on a QImage, the painting can be performed in another 
thread than the current GUI thread."


Thanks,

Dan Allen.


On 03/04/17 14:49, william.croc...@analog.com wrote:

On 04/01/2017 09:48 AM, Dan Allen wrote:

Hi Bill,

I agree, however when the print is quite complex it makes the GUI very
unresponsive.

Painting into an off screen image is not GUI related. The print 
preview could
show something like "Generating Preview" while a background thread 
generates it
and then show it when it's ready for example. This would prevent the 
GUI from
seeming unresponsive to the user. I wasn't sure if there was a 
current method to

do something like this.



Yes. We agree that the actual printing is non GUI, but if you want
to show a print preview or progress meter, that is GUI and needs
to stay in the main thread.

So, something like:
- Create a progress meter dialog.
- Start your printing in a sub thread.
- The main thread waits, perhaps in a sub-QEventLoop, servicing events.
- After a few seconds, if printing has not completed, show the dialog.
- The sub-event loop monitors the printing process with a thread safe
  communication mechanism, like signals and slots.
- When the printing completes, close the dialog.
- Exit your sub-event loop.


Thanks,

Dan Allen.


On 01/04/17 13:43, william.croc...@analog.com wrote:

On 04/01/2017 03:41 AM, Dan Allen wrote:

Hi,

Could anyone tell me if it's possible to paint into a 
QPrintPreviewWidget in

another thread, and if so, how?

I have created a class to perform printing and this runs in another 
thread.
When used for printing it works fine.  However when used for the 
print preview,
nothing is shown unless I force the signal to either 
Qt::DirectConnection (i.e.
use the GUI thread) or Qt ::BlockingQueuedConnection (i.e. block 
the GUI

thread).


Dan:

Conventional wisdom, if not the rule of law, states that all GUI 
activity

should be done from the main thread. You may just be experiencing
the Qt library enforcing this rule.

Bill


Thanks,

Dan Allen.


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




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



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




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



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

Re: [Interest] QML WebView modules

[Nibedit Dey]

Hi Mark,

Qt WebEngine is only supported on desktop platforms.Hence Linux is
supported.
It's not supported on mobile platforms yet .So Qt 5.5.1 doesn't support.
Refer: https://doc.qt.io/archives/qt-5.5/qtmodules.html

To use WebView module, in pro file add:
QT += webkit
greaterThan(QT_MAJOR_VERSION, 4):QT+=webkitwidgets

For WebEngine module add:
QT += webengine

In both cases, Linux should be working.

Regards,
Nibedit
.


-- Forwarded message --
From: Mark Tucker 
Date: Tue, Apr 4, 2017 at 3:56 PM
Subject: [Interest] QML WebView modules
To: "interest@qt-project.org" 


Hi,



I'm currently trying to create a QML app that works on both a Linux
platform and an Android platform. Due to the nature of my target platforms
(embedded systems), I'm limited to Qt 5.5.1 and cannot upgrade.



Note that my app is pure QML and I cannot write any C++ code to solve this.



To get the app running on Android, I can put "import QtWebView 1.1" into my
QML file imports, and then create a simple WebView component and set its
URL and that works.



That same import doesn't work for me on Linux, however. I can use either
"import QtWebKit 3.0" or "import QtWebEngine 1.1" (with the latter,
changing my WebView to a WebEngineView too) and I can then see a webview
that works with no issues, but neither of those are available on my Android
target (nor, from what I understand, will they ever be).



So, is there a way I can get the QtWebView import working on Linux? I can't
seem to figure out how to build it, or if it's even a valid option.



If not, then I guess that means I'll need to have different QML for both
Linux and Android…



Thanks in advance



Mark

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

[Interest] Using QAndroidStyle without depending on private headers?

[Nikos Chantziaras]

If I don't do:

  QT += widgets-private

in the project file, and then:

  #include 
  // ...
  app.setStyle(new QAndroidStyle);

then I'm getting the default style (Fusion, I think) on Android on 
subsequent runs of the application. The android style is only used the 
very first time the application runs. Afterwards, Fusion is used, unless 
the user goes to the Android application information screen and clicks 
on "Clear Data."


Is this normal? I'd like to not depend on private headers.

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

Re: [Interest] QPrintPreviewWidget

[Roland Hughes]

You know, "painting into an off screen image is not GUI related" 
__should__ be true. Haven't tried it since 4.8.x, but it certainly 
wasn't true back then. Desperately wanted to thread off the generating 
of many pixmaps which would be later BLITted onto the touch screen as 
needed by application. Nope nope nope nope. (Please, don't suggest 
alternatives to pre-loading. Embedded device, single core, no GPU trying 
to achieve 10 days of run-time battery life. Last I heard, we did it and 
we had a responsive GUI touchscreen.)


This "all things GUI in primary thread" philosophy has an awful lot of 
real world fallout, especially in the embedded world where RAM is fast 
but hardened storage is slooow. It also leads to some pretty 
horrible database interfaces, in particular when using spreadsheet/table 
models to scroll through networked/remote databases with millions of 
records where the connection could require several seconds to respond. 
Yes, I've had to do some hacks to thread that stuff off, but the primary 
examples floating around out there show it all running in the GUI thread.


Roland


On 04/04/2017 01:47 AM, interest-requ...@qt-project.org wrote:

On 04/01/2017 09:48 AM, Dan Allen wrote:

Hi Bill,

I agree, however when the print is quite complex it makes the GUI very
unresponsive.

Painting into an off screen image is not GUI related. The print preview could
show something like "Generating Preview" while a background thread generates it
and then show it when it's ready for example. This would prevent the GUI from
seeming unresponsive to the user. I wasn't sure if there was a current method to
do something like this.


Yes. We agree that the actual printing is non GUI, but if you want
to show a print preview or progress meter, that is GUI and needs
to stay in the main thread.

So, something like:
- Create a progress meter dialog.
- Start your printing in a sub thread.
- The main thread waits, perhaps in a sub-QEventLoop, servicing events.
- After a few seconds, if printing has not completed, show the dialog.
- The sub-event loop monitors the printing process with a thread safe
communication mechanism, like signals and slots.
- When the printing completes, close the dialog.
- Exit your sub-event loop.


Thanks,

Dan Allen.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/

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

[Interest] WebEngineView memory cache

[Jani Tykka]

Hi,

WebEngineViews has possibility to set:
profile.httpCacheType: WebEngineProfile.MemoryHttpCache

Even though memory cache is set I can see that WebCache directory is
created and data written there. Is this a bug or do you think it works
as expected?

Jani

-- 


This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. If 
you are not the intended recipient and have received this email in error, 
please notify BroadSoft, Inc. immediately by replying to this message, and 
destroy all copies of this message, along with any attachment, prior to 
reading, distributing or copying it.

Ce message confidentiel  et les éventuelles pièces jointes sont à l’usage 
exclusif de son ou de sa destinataire. Il est interdit, pour toute autre 
personne, de le distribuer, d’en dévoiler le contenu ou de le reproduire. 
Si vous avez reçu cette communication par erreur, veuillez en informer 
immédiatement l’expéditeur par courrier électronique et détruire l’original 
de ce message ainsi que toute copie.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QML WebView modules

[Mark Tucker]

Hi,

I'm currently trying to create a QML app that works on both a Linux platform 
and an Android platform. Due to the nature of my target platforms (embedded 
systems), I'm limited to Qt 5.5.1 and cannot upgrade.

Note that my app is pure QML and I cannot write any C++ code to solve this.

To get the app running on Android, I can put "import QtWebView 1.1" into my QML 
file imports, and then create a simple WebView component and set its URL and 
that works.

That same import doesn't work for me on Linux, however. I can use either 
"import QtWebKit 3.0" or "import QtWebEngine 1.1" (with the latter, changing my 
WebView to a WebEngineView too) and I can then see a webview that works with no 
issues, but neither of those are available on my Android target (nor, from what 
I understand, will they ever be).

So, is there a way I can get the QtWebView import working on Linux? I can't 
seem to figure out how to build it, or if it's even a valid option.

If not, then I guess that means I'll need to have different QML for both Linux 
and Android...

Thanks in advance

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

Re: [Interest] Qt3D simple geometry example

[Sean Harmer]

Hi,

On Tuesday 04 April 2017 11:55:18 Igor Mironchik wrote:
> Hi,
> 
> Thank you.
> 
> In QPlainGeometry I found that they use position, texture coordinate,
> normal and tangent to describe vertex data.
> 
> So my question is - why they need tangent, and why tangent defined with
> 4 floats?
> 
> //tangent
> 
> *fptr++=1.0f;
> 
> *fptr++=0.0f;
> 
> *fptr++=0.0f;
> 
> *fptr++=1.0f;

It depends what you want to do with the geometry in your shaders. The tangent 
is usually needed as part of normal mapping. If your shaders don't do that, 
then you may not need the tangent vectors. It's up to you to decide what 
vertex attributes you need to cater for what you want to do in your shaders.

Cheers,

Sean

> 
> 04.04.2017 11:05, Oleg Evseev пишет:
> > Hi, Igor
> > 
> > Take a look on this examples in qt3d/tests/manual folder:
> > 
> > custom-mesh-cpp
> > custom-mesh-qml
> > custom-mesh-update-data-cpp
> > custom-mesh-update-data-qml
> > 
> > I think they are exactly what you need.
> > 
> > With regards, Oleg.
> > 
> > 2017-04-04 11:01 GMT+03:00 Igor Mironchik  > 
> > >:
> > Hello,
> > 
> > Did anybody see any very simple example of Qt3D geometry creation.
> > Let it be a simple plain ellipse. Can anybody explain in a few
> > words what should be done to generate such geometry in 3D.
> > 
> > Thank you.
> > 
> > ___
> > Interest mailing list
> > Interest@qt-project.org 
> > http://lists.qt-project.org/mailman/listinfo/interest
> > 

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt3D simple geometry example

[Igor Mironchik]

Hi,

Thank you.

In QPlainGeometry I found that they use position, texture coordinate, 
normal and tangent to describe vertex data.


So my question is - why they need tangent, and why tangent defined with 
4 floats?


//tangent

*fptr++=1.0f;

*fptr++=0.0f;

*fptr++=0.0f;

*fptr++=1.0f;


04.04.2017 11:05, Oleg Evseev пишет:

Hi, Igor

Take a look on this examples in qt3d/tests/manual folder:

custom-mesh-cpp
custom-mesh-qml
custom-mesh-update-data-cpp
custom-mesh-update-data-qml

I think they are exactly what you need.

With regards, Oleg.

2017-04-04 11:01 GMT+03:00 Igor Mironchik >:


Hello,

Did anybody see any very simple example of Qt3D geometry creation.
Let it be a simple plain ellipse. Can anybody explain in a few
words what should be done to generate such geometry in 3D.

Thank you.

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






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

Re: [Interest] Is the QtOpenGLExtensions module official?

[Sean Harmer]

On Thursday 16 March 2017 20:52:30 Stefan Monov wrote:
> Hi.
> 
> I need to do something very simple - use OpenGL extensions in my Qt
> code. For this, I've found this link [1] which says the best way is
> the QtOpenGLExtensions module. But this module doesn't exist in the
> documentation. Does anyone know why?

It literally just wraps up the corresponding OpenGL extension functions in one 
class per extension. Yes you can use it, the docs would literally be forwards 
to the OpenGL extension registry. I didn't get around to autogenerating those 
yet and I'm not going to write them by hand. :)

Cheers,

Sean

> 
> TIA,
> Stefan
> 
> [1] http://www.kdab.com/opengl-in-qt-5-1-part-1/
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt3D simple geometry example

[Oleg Evseev]

Hi, Igor

Take a look on this examples in qt3d/tests/manual folder:

custom-mesh-cpp
custom-mesh-qml
custom-mesh-update-data-cpp
custom-mesh-update-data-qml

I think they are exactly what you need.

With regards, Oleg.

2017-04-04 11:01 GMT+03:00 Igor Mironchik :

> Hello,
>
> Did anybody see any very simple example of Qt3D geometry creation. Let it
> be a simple plain ellipse. Can anybody explain in a few words what should
> be done to generate such geometry in 3D.
>
> Thank you.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Qt3D simple geometry example

[Igor Mironchik]

Hello,

Did anybody see any very simple example of Qt3D geometry creation. Let 
it be a simple plain ellipse. Can anybody explain in a few words what 
should be done to generate such geometry in 3D.


Thank you.

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

Re: [Interest] Will QtWebEngine Available for Mobile?

[Jake Petroules]

No, it won't (this is in large part due to platform restrictions, especially on 
iOS).

Can you elaborate on why QtWebView is not flexible enough for your use case?

> On Mar 16, 2017, at 12:31 PM, Programcı Kanguru 
>  wrote:
> 
> Hi;
> WebView is available for mobile, but it's not flexible. Will QtWebEngine 
> available for Android, iOS, Windows Mobile ...? Thanks.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

[Interest] Qt Bulgarian translation

[Любомир Василев]

Hello!

I have translated all of the Qt localisation files to Bulgarian. I 
didn't post here first, as I communicated with Oswald Buddenhagen, and 
understood that there is no such translation started. Moreover, I didn't 
want to communicate in the open, until I have something to show, but I 
managed to complete the whole thing. I have posted a patch with the 
translations in /gerrit/ here: https://codereview.qt-project.org/#/c/188772/


If anyone is interested in reviewing the translations, please do. Here 
is some information about the translation:


 * I have translated all the files by first converting them to PO and
   using POEdit, and then back to TS (removed the extra PO tags in the
   beginning).
 * While translating, I was looking at the programs to see the string
   in context, where that is possible, like looked in Designer,
   Linguist, Assistant.
 * I have also used the Russian and Ukrainian (being similar languages)
   translated files for extra information/context/ideas.
 * I am a programmer, so I understand all the technical terms and have
   taken care to translate them with the proper Bulgarian terms or
   explain them sufficiently well, where there is no accepted
   translation. Of course, established abbreviations, etc., that are
   widely known, are left in their original form.
 * I have translated all the files myself, meaning all terms'
   translations are consistent across all files, the style is the same,
   etc.
 * Everything is spell-checked, as POEdit automatically highlights the
   errors.

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

[Interest] Will QtWebEngine Available for Mobile?

[Programcı Kanguru]

Hi;
WebView is available for mobile, but it's not flexible. Will QtWebEngine
available for Android, iOS, Windows Mobile ...? Thanks.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Is the QtOpenGLExtensions module official?

[Stefan Monov]

Hi.

I need to do something very simple - use OpenGL extensions in my Qt
code. For this, I've found this link [1] which says the best way is
the QtOpenGLExtensions module. But this module doesn't exist in the
documentation. Does anyone know why?

TIA,
Stefan

[1] http://www.kdab.com/opengl-in-qt-5-1-part-1/
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest