Re: [Interest] mirroring and reversing QMovie

2016-07-11 Thread Thiago Macieira 
On terça-feira, 12 de julho de 2016 15:48:47 PDT Frank Rueter | OHUfx wrote:
> Hi all,
> 
> I am wondering how to mirror a cached QMovie object horizontally and
> vertically and how to play it in reverse.
> Is this even achievable with QMovie? If not could it be achieved by
> manipulating the IODevice somehow?
> I can't find a single thing online about this sort of thing.

Forget about playing it in reverse. Movie files are encoded in such a way that 
the frame N+1 depends on the rendering of frame N. To play in reverse, you 
need to render all of the non-key frames, store them in memory, then display 
them.

That's why rewinding on moving players is usually choppy, while fast-forward 
can be smooth: rewinding often simply displays the key frames.

-- 
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] mirroring and reversing QMovie

2016-07-11 Thread Frank Rueter | OHUfx 

Hi all,

I am wondering how to mirror a cached QMovie object horizontally and 
vertically and how to play it in reverse.
Is this even achievable with QMovie? If not could it be achieved by 
manipulating the IODevice somehow?

I can't find a single thing online about this sort of thing.

Cheers,
frank

--
ohufxLogo 50x50  	*vfx compositing 
 | *workflow customisation 
and consulting * *


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

Re: [Interest] FLex / Bison and QT4 4.8.1 Win32 interaction

2016-07-11 Thread K. Frank 
Hi Fabio (and Scott)!

On Mon, Jul 11, 2016 at 8:22 PM, Scott Aron Bloom  wrote:
> My company uses Cygwin’s Flex and Bison.
>
> We use CMake, and had to create our own module for Flex and Bison, not too
> hard, but if you are using qmake, I cant help.
>
> He have no problem with the build step from .y to .h and .cpp

Scott's comment makes me realize that I should correct my earlier
misguided comment.

Lex / yacc, flex / bison are not libraries that get linked into your
application -- rather they are free-standing applications themselves
that produce compilable source files.  So all of my nonsense about
needing to build flex / bison with the same (or compatible) compiler
as you used to build qt and your application is just wrong.

You just need to find a version of the flex and bison executable that
will run on your build machine.  As Scott mentioned, you could run
cygwin (a unix emulator for windows) on a windows machine, and
use its version of flex / bison.  Or you could find a native (i.e.,
non--cygwin) windows version of flex / bison.  I imagine that there
is one out there.  (Michael mentioned that gnuwin32, as shipped
with qt5, contains a version of flex / bison.)

Lastly, your build machine  doesn't have to be windows.  You could,
for example, build your windows qt executable by cross-compiling
on a linux machine, and run linux's version of flex / bison on that
linux build machine.

Or, if your parser is stable -- i.e., doesn't need to be modified as
you maintain and upgrade your application -- you could (hackishly)
just copy over the parser code (the output of flex / bison) to a
windows build machine, and remove the flex / bison processing
step from your build process.  (This, of course, would be very
EVIL (TM), and violate all manner of good-housekeeping source
control practices.)

Sorry for the previous noise.  There's no compiler compatibility issue,
so I can't see any reason you would need (or want) to build flex /
bison from source.  Simply find pre-built flex / bison executables
that run on your build machine.

As a side comment, Bill suggested that you might pass on flex / bison,
and hand-code your own parser.  There is some aspirational virtue to
Bill's view, and it might even make sense if you were starting a new
project.  But given that you already have a working, tested, field-tested
flex / bison grammar for your application's parser, rewriting that parser
by hand would be a bad idea, falling clearly into the "if it ain't broke,
don't fix it" category of time-sucking mistakes.

> Scott


Again, sorry for my earlier nonsense.


Happy Parser-Generating!


K. Frank


> [mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf
> Of Fabio Giovagnini
> ...
>
> Thanks guys. But under linux my tool has been working 10 years long flex/
> bison based. So i must to make them working under windows. Thanks alot. By
> the way from a certain standing point i agree with the "from the scretch"
> solution. But i had to think about it 10 years ago... now it is a bit late
> :-) ciao
> Fabio
>
> On 07/07/2016 08:01 PM, Fabio Giovagnini wrote:
>
> Thanks Frank. So you suggest to build from the sources. I' try. Thanks again
> ...
> Il 07/lug/2016 17:40, "K. Frank"
> ha scritto:
>
> Ciao Fabio!
>
> On Thu, Jul 7, 2016 at 7:19 AM, Fabio Giovagnini  > wrote:
> >  Ciao to all.
> >  I have an application linux native based on:
> >  1) qt4 (4.8.1)
> >  3) lex/bison
> >
> >  Under Ubuntu 14.04 and prevoius everithing ok.
> >
> >  Under Windows, I cannot find lex/bison support.
> >  I have to say that I installed only QT SDK (w/ MinGW support)
> >  Any suggestion will be really appreciated.
>
> Windows does not come with built-in flex / bison support, nor
> does mingw, nor (to the best of my knowledge) does Qt. (This
> is true of a lot of unix-world libraries that are nearly universal
> on various flavors of unix.)
>
> I would expect (but don't know for a fact) that you could find a
> third-party port of flex / bison to windows that you could then
> use for your Qt / flex / bison project. In general, you would be
> best off if you found a port built with the same compiler as your
> Qt project (apparently mingw). One way to insure this would be
> to build it yourself. If you're careful and know what your doing
> you can sometimes get away with using c libraries compiled with
> a different compiler (For example, the ms system calls were not
> compile with mingw and you can call into those.), but it's likely to
> be more bother trying to mix compilers than compiling something
> like flex / bison yourself.
>
> >  Thanks
> >  Fabio
>
> Happy Parsing!
>
> K. Frank
> ...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

2016-07-11 Thread John C. Turnbull 
Anyone? 

> On 10 Jul 2016, at 23:23, John C. Turnbull  wrote:
> 
> I am still new to Qt but am very interested in the technology and the deep 
> innards of how it functions. I have worked in a 3D animation studio and 
> learned a lot while I was there.
> 
> Is there documentation or articles that:
> 
> 1) Describe in detail how the Qt Quick rendering pipeline is designed and how 
> it operates.
> 
> 2) Describe the structure and overall architecture of the Qt Quick Scenegraph 
> and how it is rendered?
> 
> 3) Describe the steps that have been taken so far and any further steps 
> planned to optimise both (1) and (2)?
> 
> I really want to know how all this hangs together as I may be able to further 
> optimise and improve aspects of them.
> 
> -jct
> 
>>> On 10 Jul 2016, at 22:24, Uwe Rathmann  wrote:
>>> 
>>> On Fri, 08 Jul 2016 18:51:47 +0200, Giuseppe D'Angelo wrote:
>>> 
>>> This seems _very_ interesting and worth researching, are you going to
>>> share some results during the QtCon session you mentioned earlier?
>> 
>> When time has come I will release my package under a Open Source License, 
>> but I first need to reach a certain level of features and quality. But at 
>> least Andrew ( when I can't make it myself ) will have the code with him.
>> 
>> We have not yet decided which details we like to present, but to be 
>> honest I wouldn't consider details of this vertex list generation being 
>> the most interesting aspect. The features are quite obvious, the 
>> implementation is in line with the design of the other QSG classes ( very 
>> similar to what you find in QSGRectangleNode ) - nothing specific sexy, 
>> it's simply: someone has to do it.
>> 
>> An approach I would prefer to what I have today is some sort of paint 
>> engine. Something you could feed - at least - with a painter path - that 
>> spits out vertex lists.
>> 
>> Maybe more interesting from my point of view is code, that is currently 
>> implemented inside of QQuick classes, but could be moved to more 
>> lightweight QSG classes. F.e creating texture nodes with QPainter or the 
>> node tree generation for texts ( currently I'm needs a static QQuickText 
>> item as helper ).
>> 
>> --
>> 
>> But when it comes to the QQuick classes my way of thinking is often 
>> controversial to the existing code:
>> 
>> I would like to have the C++ class APIs more compliant with what I 
>> consider being "well established Qt standards".
>> 
>> The Quick framework itself could be smarter: stuff like not calling 
>> updatePaintNode for invisible items or delaying expensive operations 
>> until updatePolish ( where the layout is stable ) are obvious examples
>> for how to improve the overall performance.
>> 
>> Uwe
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] [QtCharts] Logarithmic QDateTimeAxis

2016-07-11 Thread Thompson, Adam B. 
The software package I co-develop at work is dependent on Qt 4.8, but we plan 
to move to Qt 5 when we have time/funding. We currently depend on a third-party 
plotting package for our 2D data visualization, but we'd like to be able to use 
QtCharts when we upgrade.
Some of our data sets are time-dependent and are often extrapolated hundreds or 
thousands of years in the future. As such, a logarithmic time scale would be 
quite useful, if not necessary to view the data in a truly meaningful manner.
Can anyone provide guidance on properly extending QDateTimeAxis (, 
QLogValueAxis, or QAbstractAxis) to provide a logarithmic time scale as I've 
described?
Adam Thompson
Computer Scientist, Nuclear Engineering
Oak Ridge National Laboratory
+1.865.241.8062
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] FLex / Bison and QT4 4.8.1 Win32 interaction

2016-07-11 Thread Scott Aron Bloom 
My company uses Cygwin’s Flex and Bison.

We use CMake, and had to create our own module for Flex and Bison, not too 
hard, but if you are using qmake, I cant help.

He have no problem with the build step from .y to .h and .cpp
Scott



From: Interest 
[mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf Of 
Fabio Giovagnini
Sent: Sunday, July 10, 2016 9:28 PM
To: william.croc...@analog.com
Cc: interest@qt-project.org
Subject: Re: [Interest] FLex / Bison and QT4 4.8.1 Win32 interaction


Thanks guys. But under linux my tool has been working 10 years long flex/ bison 
based. So i must to make them working under windows. Thanks alot. By the way 
from a certain standing point i agree with the "from the scretch" solution. But 
i had to think about it 10 years ago... now it is a bit late :-) ciao
Fabio
On 07/07/2016 08:01 PM, Fabio Giovagnini wrote:
Thanks Frank. So you suggest to build from the sources. I' try. Thanks again

I suggest you just take the weekend and write your own
parser and lexical analysis, void of Flex and Bison.
I did and I have never looked back.

:-)

Bill
Il 07/lug/2016 17:40, "K. Frank" 

>> ha scritto:

Ciao Fabio!

On Thu, Jul 7, 2016 at 7:19 AM, Fabio Giovagnini 

>> wrote:
>  Ciao to all.
>  I have an application linux native based on:
>  1) qt4 (4.8.1)
>  3) lex/bison
>
>  Under Ubuntu 14.04 and prevoius everithing ok.
>
>  Under Windows, I cannot find lex/bison support.
>  I have to say that I installed only QT SDK (w/ MinGW support)
>  Any suggestion will be really appreciated.

Windows does not come with built-in flex / bison support, nor
does mingw, nor (to the best of my knowledge) does Qt. (This
is true of a lot of unix-world libraries that are nearly universal
on various flavors of unix.)

I would expect (but don't know for a fact) that you could find a
third-party port of flex / bison to windows that you could then
use for your Qt / flex / bison project. In general, you would be
best off if you found a port built with the same compiler as your
Qt project (apparently mingw). One way to insure this would be
to build it yourself. If you're careful and know what your doing
you can sometimes get away with using c libraries compiled with
a different compiler (For example, the ms system calls were not
compile with mingw and you can call into those.), but it's likely to
be more bother trying to mix compilers than compiling something
like flex / bison yourself.

>  Thanks
>  Fabio


Happy Parsing!


K. 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
___
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] readyRead() signal issues with QTcpSopcket and Qt 5.6 under minGW

2016-07-11 Thread Thiago Macieira 
On segunda-feira, 11 de julho de 2016 20:37:08 PDT Etienne Sandré-Chardonnal 
wrote:
> I have tried to reconstruct a minimal application doing the same, and I
> could not reproduce the bug. So I will have to strip the main application
> part by part in order to make one. This will take some time but I will do
> it.

Indeed. I am quite skeptical that we somehow regressed this critical 
functionality, but it's not outside the realm of possibility.

-- 
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] android emulator - qtcreator

2016-07-11 Thread Arno 
Hello,

I need to pass -gpu off command line option to the android emulator. How
do I do that from inside qtcreator?

I know about the ini-files for AVD, but unfortunately google hasn't
revealed the proper option to me yet, and the android GUI throws an
exception when I try to start it:
~~
> am@abydos ~ $ android
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3550 
> or swt-pi-gtk in swt.library.path, java.library.path or the jar file
> at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
> at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
> at org.eclipse.swt.internal.gtk.OS.(Unknown Source)
> at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
> at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
> at org.eclipse.swt.widgets.Display.(Unknown Source)
> at com.android.sdkmanager.Main.showSdkManagerWindow(Main.java:403)
> at com.android.sdkmanager.Main.doAction(Main.java:391)
> at com.android.sdkmanager.Main.run(Main.java:151)
> at com.android.sdkmanager.Main.main(Main.java:117)
~~

It's an archlinux VM with X11Forwarding to another linux box, if that helps.

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

Re: [Interest] QtCreator - include(...) - Possible bug

2016-07-11 Thread Thiago Macieira 
On segunda-feira, 11 de julho de 2016 18:44:47 PDT Florian K wrote:
> Hello,
> 
> I've recently asked a question about adding and compiling external source
> files of another project, as this has seemed to fail. The moderator JKSH on
> the Qt-Forums
>  iles/6> has suggested to test if a path without spaces works, which indeed
> worked.
> 
> //Inside a ".pro" file
> //This apparently works and source files are
> compiled.include(C:/ProjDir/ProjName.pri)//This works too, the source
> files are correctly included in the
> //project (QtCreator), but these source files are NOT being
> compiled.include("../../Visual Studio
> 2015/Projects/ProjDir/ProjName.pri")
> 
> Now my question is, if this is a known bug, or if something else is wrong
> here. To me it appears to be a bug.

First of all, because you said this is a problem with Qt Creator: does it 
happen without Qt Creator too? That is, does it happen if you just run qmake 
on the command-line? You can test it too by trying to build inside Qt Creator.

If you only see squiggly lines under that and/or Qt Creator parsing errors, 
the problem is something else.

-- 
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] QtCreator - include(...) - Possible bug

2016-07-11 Thread Florian K 
Hello,

I've recently asked a question about adding and compiling external source
files of another project, as this has seemed to fail. The moderator JKSH on
the Qt-Forums

has suggested to test if a path without spaces works, which indeed worked.

//Inside a ".pro" file
//This apparently works and source files are
compiled.include(C:/ProjDir/ProjName.pri)//This works too, the source
files are correctly included in the
//project (QtCreator), but these source files are NOT being
compiled.include("../../Visual Studio
2015/Projects/ProjDir/ProjName.pri")

Now my question is, if this is a known bug, or if something else is wrong
here. To me it appears to be a bug.

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

Re: [Interest] readyRead() signal issues with QTcpSopcket and Qt 5.6 under minGW

2016-07-11 Thread Thiago Macieira 
On segunda-feira, 11 de julho de 2016 15:47:17 PDT Etienne Sandré-Chardonnal 
wrote:
> Hi Thiago,
> 
> After further investigation, the issue is not related to TCP but to
> threads/events. It's on client (ie sender) side.
> 
> I have the following order of events :
> 
> Client * client = new Client(host, this);
> QThread * clientThread = new QThread(this);
> client->moveToThread(clientThread);
> connect(this, SIGNAL(sendClientCommand(QString)), client, SLOT(command(
> QString)));

Does the command(QString) really take that much CPU time to create the command 
message to be sent over the socket that you need it to run on a separate 
thread?

And by "that much", I mean A LOT of CPU time. If you can't say that is the 
case, stop using threads.

> So I have a signal connected to an object's slot in another thread. I emit
> the signal before the thread is started. I do not know if this is correct,
> but :
> 
>- With Qt 5.4 the command("loadstart") slot is properly called as soon
>as possible
>- With Qt 5.6 the slot is not called until I emit the signal again, as
>if the event was queued, but the queue not processed until another event
> is sent.

Ok, that description sounds like a really serious event dispatching issue. Can 
you reduce this to a testcase?

> Also, if I add a Client::threadStarted() slot calling processEvents() and
> connect it to QThread::started() slot of clientThread, then the command
> slot is processed on time. I do not know if this is an effect of
> processEvents() or if this is because the connection is also queued, thus
> waking up the event loop.
> Can this be a Qt bug or am I misusing the queued connection?

Your description makes it sound like a serious Qt bug. That's why I need the 
testcase.

-- 
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] readyRead() signal issues with QTcpSopcket and Qt 5.6 under minGW

2016-07-11 Thread Etienne Sandré-Chardonnal 
Hi Thiago,

After further investigation, the issue is not related to TCP but to
threads/events. It's on client (ie sender) side.

I have the following order of events :

Client * client = new Client(host, this);
QThread * clientThread = new QThread(this);
client->moveToThread(clientThread);
connect(this, SIGNAL(sendClientCommand(QString)), client, SLOT(command(
QString)));
connect(client, SIGNAL(messageSent(QString)), this, SLOT
(messageFromClient(QString)));
QTimer::singleShot(0, clientThread , SLOT(start()));  //Differed start
required to avoid missing messages
emit sendClientCommand("loadstart");



So I have a signal connected to an object's slot in another thread. I emit
the signal before the thread is started. I do not know if this is correct,
but :

   - With Qt 5.4 the command("loadstart") slot is properly called as soon
   as possible
   - With Qt 5.6 the slot is not called until I emit the signal again, as
   if the event was queued, but the queue not processed until another event is
   sent.

Also, if I add a Client::threadStarted() slot calling processEvents() and
connect it to QThread::started() slot of clientThread, then the command
slot is processed on time. I do not know if this is an effect of
processEvents() or if this is because the connection is also queued, thus
waking up the event loop.
Can this be a Qt bug or am I misusing the queued connection?

Thanks





2016-07-09 21:01 GMT+02:00 Thiago Macieira :

> On sábado, 9 de julho de 2016 15:19:23 PDT Etienne Sandré-Chardonnal wrote:
> > After additional tests, bytesAvailable() is not growing either.
> >
> > So on the sender, the packet has been sent, and the QTcpSocket flushed,
> > On the receiver, I have no readyRead signal(), and bytesAvailable() is
> zero.
>
> The first rule of checking networking problems is isolating the problem to
> either the sender or the receiver.
>
> Please use a packet sniffer and tell us whether the problem is:
>  a) packet was never sent from the sender machine
>  b) packet was sent from the sender but the receiver didn't ACK it
>  c) packet was sent and ACK'ed, but the application didn't receive it
>
> --
> 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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML 5.7 QNX, module (or version) is not installed

2016-07-11 Thread Julien Bordes 
I don't have any other clue about the Virtual keyboard I will fill a bug 
report...

Nevertheless for QtWebkit as i told you below, the problem seems a little bit 
different. My application (called webbrowser) find the plugin but it seems the 
version 3.0 of the module is not installed.

Is there a way to know which version of a module is available on the system?


>> Hi,
>> It maybe something simple:
>> If the library is there I would check the usual suspects like look if 
>> something is missing or cannot be found on your machine so that it cannot 
>> run (“ldd libqtvirtualkeyboardstylesplugin.so”). There may be an (r)path, 
>> etc. problem > or a required library is indeed not installed.
>> - Michael.
>
> Hello Michael,
>
> I didn't set any RPATH in my application but I set the paths for Qt 5.7 on 
> the i.MX6 target (see my first post 
> http://lists.qt-project.org/pipermail/interest/2016-June/023323.html)
>
> -
> Virtual Keyboard plugin
>
> # ldd /opt/qt5.7/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so
> /opt/qt5.7/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so:
> libqtvirtualkeyboardplugin.so => 
> /opt/qt5.7/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so 
> (0x7800)
> libQt5Quick.so.5 => /opt/qt5.7/lib/libQt5Quick.so.5 (0x7810)
> libQt5Gui.so.5 => /opt/qt5.7/lib/libQt5Gui.so.5 (0x7840)
> libQt5Qml.so.5 => /opt/qt5.7/lib/libQt5Qml.so.5 (0x7880)
> libQt5Network.so.5 => /opt/qt5.7/lib/libQt5Network.so.5 (0x78ab)
> libsocket.so.3 => /base/lib/libsocket.so.3 (0x7809)
> libQt5Core.so.5 => /opt/qt5.7/lib/libQt5Core.so.5 (0x78c0)
> libm.so.2 => /proc/boot/libm.so.2 (0x780c)
> libGLESv2.so.1 => /base/usr/lib/libGLESv2.so.1 (0x780b4000)
> libEGL.so.1 => /base/usr/lib/libEGL.so.1 (0x780e3000)
> libcpp.so.5 => /base/lib/libcpp.so.5 (0x783a)
> libpng14.so.0 => /base/usr/lib/libpng14.so.0 (0x7879)
> libz.so.2 => /base/usr/lib/libz.so.2 (0x780ed000)
> libslog2.so.1 => /base/lib/libslog2.so.1 (0x78398000)
> libicui18n.so.49 => /base/usr/lib/libicui18n.so.49 (0x7900)
> libicuuc.so.49 => /base/usr/lib/libicuuc.so.49 (0x7911)
> libicudata.so.49 => /base/usr/lib/libicudata.so.49 (0x7920)
> libpps.so.1 => /proc/boot/libpps.so.1 (0x78781000)
> libcpp-ne.so.5 => /base/lib/libcpp-ne.so.5 (0x78ba)
>
> -
> Virtual Keyboard Style plugin
>
> # ldd 
> /opt/qt5.7/qml/QtQuick/VirtualKeyboard/Styles/libqtvirtualkeyboardstylesplugin.so
> /opt/qt5.7/qml/QtQuick/VirtualKeyboard/Styles/libqtvirtualkeyboardstylesplugin.so:
> libqtvirtualkeyboardstylesplugin.so => 
> /opt/qt5.7/qml/QtQuick/VirtualKeyboard/Styles/libqtvirtualkeyboardstylesplugin.so
>  (0x7800)
> libQt5Quick.so.5 => /opt/qt5.7/lib/libQt5Quick.so.5 (0x7810)
> libQt5Svg.so.5 => /opt/qt5.7/lib/libQt5Svg.so.5 (0x7801)
> libQt5Widgets.so.5 => /opt/qt5.7/lib/libQt5Widgets.so.5 (0x7840)
> libQt5Gui.so.5 => /opt/qt5.7/lib/libQt5Gui.so.5 (0x7890)
> libQt5Qml.so.5 => /opt/qt5.7/lib/libQt5Qml.so.5 (0x78d0)
> libQt5Network.so.5 => /opt/qt5.7/lib/libQt5Network.so.5 (0x78fb)
> libsocket.so.3 => /base/lib/libsocket.so.3 (0x7805)
> libQt5Core.so.5 => /opt/qt5.7/lib/libQt5Core.so.5 (0x7910)
> libm.so.2 => /proc/boot/libm.so.2 (0x7808)
> libGLESv2.so.1 => /base/usr/lib/libGLESv2.so.1 (0x78074000)
> libEGL.so.1 => /base/usr/lib/libEGL.so.1 (0x780a3000)
> libcpp.so.5 => /base/lib/libcpp.so.5 (0x783a)
> libz.so.2 => /base/usr/lib/libz.so.2 (0x780b)
> libpng14.so.0 => /base/usr/lib/libpng14.so.0 (0x780d)
> libslog2.so.1 => /base/lib/libslog2.so.1 (0x780c2000)
> libicui18n.so.49 => /base/usr/lib/libicui18n.so.49 (0x7950)
> libicuuc.so.49 => /base/usr/lib/libicuuc.so.49 (0x7961)
> libicudata.so.49 => /base/usr/lib/libicudata.so.49 (0x7970)
> libpps.so.1 => /proc/boot/libpps.so.1 (0x780ca000)
> libcpp-ne.so.5 => /base/lib/libcpp-ne.so.5 (0x7884)
>
> -
> Application
>
> # ldd ./basic
> ./basic:
> libQt5Quick.so.5 => /opt/qt5.7/lib/libQt5Quick.so.5 (0x7800)
> libQt5Gui.so.5 => /opt/qt5.7/lib/libQt5Gui.so.5 (0x7830)
> libQt5Qml.so.5 => /opt/qt5.7/lib/libQt5Qml.so.5 (0x7870)
> libQt5Network.so.5 => /opt/qt5.7/lib/libQt5Network.so.5 (0x789b)
> libsocket.so.3 => /base/lib/libsocket.so.3 (0x782a)
> libQt5Core.so.5 => /opt/qt5.7/lib/libQt5Core.so.5 (0x78b0)
> libm.so.2 => /proc/boot/libm.so.2 (0x782d)
> libGLESv2.so.1 => /base/usr/lib/libGLESv2.so.1 (0x782c4000)
> libEGL.so.1 => /base/usr/lib/libEGL.so.1 (0x782f3000)
> libcpp.so.5 => /base/lib/libcpp.so.5 (0x7869)
> libc.so.3 => /usr/lib/ldqnx.so.2 (0x100)
> libpng14.so.0 => /base/usr/lib/libpng14.so.0 (0x78aa)
> libz.so.2 => /base/usr/lib/libz.so.2 (0x786ec000)
> libslog2.so.1 => /base/lib/libslog2.so.1 (0x78298000)
>

[Interest] Qt5 print dialogue for linux/cups - "ppd options"

2016-07-11 Thread Thomas Kleindienst 

May I raise this topic again?:

http://lists.qt-project.org/pipermail/interest/2015-September/018692.html

I'd like to get some information wether it is planned to "recover" the "ppd 
options" for qt5?

Many printers provide extra functionality like stapling, stitching etc... 
through the ppd options. I think, it would be a shame if this functionality is 
lost for qt5 based apps.

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