Am 07.06.2011 um 09:04 schrieb Thiago Macieira thi...@kde.org:
Qt wants to use this platform plugin. The code to load it is inside QtGui. So
Qt might load it and the style plugin regardless of what you wanted.
Ok, now I get it: And this style plugin, located somewhere on the system, also
08.06.2011, 10:50, Till Oliver Knoll till.oliver.kn...@gmail.com:
I can't imagine that LD_LIBRARY_PATH would even take precedence even over
system default paths such as /usr/lib!
Why are you surprised?
For example, your application is bundled with it's own copy of Qt libs, and
there's
On Wednesday, 8 de June de 2011 08:50:55 Till Oliver Knoll wrote:
Ok, now I get it: And this style plugin, located somewhere on the system,
also depends on Qt, and not being aware of the bundled Qt (inside the
application folder) it also pulls *another* instance - the Qt libs located
on the
On Wednesday, 8 de June de 2011 10:55:54 Till Oliver Knoll wrote:
Well, let me elaborate: on Windows the equivalent of LD_LIBRARY_PATH is
PATH. That is whenever an *.exe is loaded at some point in the DLL search
order it will look into all the directories in PATH for the corresponding
DLLs. In
On Wednesday, 8 de June de 2011 12:33:39 Thiago Macieira wrote:
Since the system doesn't have a Wacom tablet, so there's no wintab32.dll in
the system dirs. When Qt probes for the Wacom drivers, it tells the system
to LoadLibrary(wintab32) and that will be resolved on the current
directory.
On Wednesday, 8 de June de 2011 14:22:47 Konstantin Tokarev wrote:
Is it enough to set style explicitly to get rid of platform plugin?
No. Setting the style will get you out of the style plugin only. Not the
platform plugins (there's more than one).
I really recommend just using dynamic
Hi,
I want to raise the topic of QtLocation in Qt5. Currently QtLocation is part
of QtMobility but is equally useful on the desktop and is something of
interest to KDE. I'm wondering what the plans are with regards to properly
supporting the desktop platforms in QtLocation?
There's a few
Hi John,
On 6/8/11 2:22 PM, ext John Layt johnl...@googlemail.com wrote:
Hi,
I want to raise the topic of QtLocation in Qt5. Currently QtLocation is
part
of QtMobility but is equally useful on the desktop and is something of
interest to KDE. I'm wondering what the plans are with regards to
- Original Message
From: Thiago Macieira thi...@kde.org
[snip]
Thiago,
As I am looking to enable both commercial licensees and FLOSS users of Qt
to
use this, what is the best licensing route? I noticed that the current
QtService component is BSD licensed[1]. Do we need to
On Tuesday, June 07, 2011 08:58:22 AM Thiago Macieira wrote:
...
LSB has lost track of what's recent. Just take a mildly old / relatively
I don't know whether I misunderstood the idea behind LSB, but even RHEL and
SLES (forgot the exact versions, they were relatively old), which claimed they
On Tuesday, June 07, 2011 08:37:06 AM Thiago Macieira wrote:
...
Note what I said before: do not ship your own Qt binaries on Linux. If you
really want to do that, I recommend either static linking or the
renaming+namespace trick.
What trick is this ?
Put all of Qt into a custom namespace ?
On Tuesday 07 June 2011 20:35:04 ext Alexander Neundorf wrote:
On Tuesday, June 07, 2011 08:37:06 AM Thiago Macieira wrote:
...
Note what I said before: do not ship your own Qt binaries on Linux. If you
really want to do that, I recommend either static linking or the
renaming+namespace
On Tuesday 07 June 2011, Oswald Buddenhagen wrote:
On 06/07/11 14:16, ext Bill Hoffman wrote:
On 6/7/2011 6:23 AM, Oswald Buddenhagen wrote:
but there is certainly room for borrowing some code or at least
algorithms - cmComputeLinkInformation.cxx for example is a bonanza of
On Tuesday 07 June 2011, Thiago Macieira wrote:
On Tuesday, 7 de June de 2011 08:16:03 Bill Hoffman wrote:
Agreed, it was a bit insane. It would be really helpful if you could
post some pseudo code that showed the use case of win32 sources and some
sources that depend on some system
Em Tuesday, 7 de June de 2011, às 20:35:04, Alexander Neundorf escreveu:
On Tuesday, June 07, 2011 08:37:06 AM Thiago Macieira wrote:
...
Note what I said before: do not ship your own Qt binaries on Linux. If
you really want to do that, I recommend either static linking or the
Am 08.06.11 12:33, schrieb Thiago Macieira:
On Wednesday, 8 de June de 2011 10:55:54 Till Oliver Knoll wrote:
Well, let me elaborate: on Windows the equivalent of LD_LIBRARY_PATH is
PATH. [...]
You know, this was a vector attack on Windows last year. It affected Qt-based
applications, like
At the risk of making myself a target. ;)
Rather than looking for a build system where an IDE can manipulate the project
file directly (eg .pro, CMakeLists.txt, etc.), is there any merit to defining
an API or command line interface which an IDE can hook into and then it is up
to the
17 matches
Mail list logo
