Clarkson, Edward C. | 2 Feb 21:03 2013
Picon

Mac qwt/qwtpolar build/install suggestions

Uwe and others--

I've run into a few problems with replicating my development environment
on my new mac (Qt 4.8.4, not Qt5), and after a lot of reading and
learning, I believe I have some simple fixes.  First, some details to help
others when google hopefully indexes this:

Qwt builds and install fine by default (caveat: I disabled MathML and
designer plugin since I don¹t need them, and I had previously changed the
default qmakespec to macx-g++, and this is against the binary 4.8 release
direct from Digia).

Based on that, I would have expected qwtpolar to do so as well (after
making quake aware of /usr/local/qwt-XXX/features)--but it compiles, but
does not link.  The issue is that the -l flag rather than the -framework
option is being passed to ld, which appears to be because the qwt copy of
qwtAddLibrary does not detect if it was built as a framework as set in
qwtconfig.pri.  The following patch to qwtfunctions.pri corrects that:

38c38,42
< 
---
>     mac {
>   contains(QWT_CONFIG, QwtFramework) {
>     LINKAGE = -framework $${LIB_NAME}$${QT_LIBINFIX}
>   }
>     }

A couple of other things I noticed and could be changed too:
- I think the use of QT_LIBINFIX in qwtfunctions.pri is from copying from
(Continue reading)

Clarkson, Edward C. | 2 Feb 23:44 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

As an addendum after I actually got my project compiling (which depends on
qwt/qwtpolar): the qtAddLibrary(qwtpolar) call needs to be changed to
qwtAddLibrary (for presumably the same reasons as the function was created
for qwt), and the qwtfunctions copied from the qwt tree to the qwtpolar
one.

On 2/2/13 3:03 PM, "Clarkson, Edward C." <Edward.Clarkson <at> gtri.gatech.edu>
wrote:

>Uwe and others--
>
>I've run into a few problems with replicating my development environment
>on my new mac (Qt 4.8.4, not Qt5), and after a lot of reading and
>learning, I believe I have some simple fixes.  First, some details to help
>others when google hopefully indexes this:
>
>Qwt builds and install fine by default (caveat: I disabled MathML and
>designer plugin since I don¹t need them, and I had previously changed the
>default qmakespec to macx-g++, and this is against the binary 4.8 release
>direct from Digia).
>
>Based on that, I would have expected qwtpolar to do so as well (after
>making quake aware of /usr/local/qwt-XXX/features)--but it compiles, but
>does not link.  The issue is that the -l flag rather than the -framework
>option is being passed to ld, which appears to be because the qwt copy of
>qwtAddLibrary does not detect if it was built as a framework as set in
>qwtconfig.pri.  The following patch to qwtfunctions.pri corrects that:
>
>38c38,42
>< 
(Continue reading)

Uwe Rathmann | 4 Feb 09:16 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

Hi Ed,

> As an addendum after I actually got my project compiling (which depends on
> qwt/qwtpolar): the qtAddLibrary(qwtpolar) call needs to be changed to
> qwtAddLibrary (for presumably the same reasons as the function was created
> for qwt), and the qwtfunctions copied from the qwt tree to the qwtpolar
> one.

The reason why qwtfunctions.prf was created is Qt 5, where the Qt
functions I was using so far are gone. QwtPolar 1.0 doesn't compile at
all with Qwt 6.1, while QwtPolar 1.1 ( = SVN trunk ) has
qwtpolarfunctions.pri. So I'm not sure which combination you have tried.

( By the way: qwtfunctions.pri gets installed and is read in
qwtpolarbuild.pri by "CONFIG += qwt". But for some reason I couldn't use
its functions in the qwtpolar project files and made the copy
qwtpolarfunctions.pri as temporary solutions instead. I prefer not
having this pointless copy - if you want to have a look at this ? )

Regarding the framework issues: please build Qwt 6.1-rc3 on the Mac
including the designer plugin and the MathML stuff and the examples.
Also try building your application using: "CONFIG += qwt". I expect that
you run into errors when linking because qwtAddLibrary() doesn't handle
frameworks ( like qtAddLibrary() does ).  Please add the missing lines
and send me a patch.

Unfortunately I don't have a Mac myself and so far the users reporting
issues with frameworks disappeared as soon as I'm asking for any support.

Uwe
(Continue reading)

Clarkson, Edward C. | 4 Feb 23:32 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

On 2/4/13 3:16 AM, "Uwe Rathmann" <Uwe.Rathmann <at> tigertal.de> wrote:
>The reason why qwtfunctions.prf was created is Qt 5, where the Qt
>functions I was using so far are gone. QwtPolar 1.0 doesn't compile at
>all with Qwt 6.1, while QwtPolar 1.1 ( = SVN trunk ) has
>qwtpolarfunctions.pri. So I'm not sure which combination you have tried.

Prior to the below, just 1.0.1 and 6.0.2 with Qt 4.8.4.

I have done nothing with Qt5 yet:  any idea what they did differently that
they don't need the function any more that qwt can copy?

>( By the way: qwtfunctions.pri gets installed and is read in
>qwtpolarbuild.pri by "CONFIG += qwt". But for some reason I couldn't use
>its functions in the qwtpolar project files and made the copy
>qwtpolarfunctions.pri as temporary solutions instead. I prefer not
>having this pointless copy - if you want to have a look at this ? )

I'll see if I can figure anything out... Do you know if that behavior is
this true on non-mac platforms too?

>Regarding the framework issues: please build Qwt 6.1-rc3 on the Mac
>including the designer plugin and the MathML stuff and the examples.
>Also try building your application using: "CONFIG += qwt". I expect that
>you run into errors when linking because qwtAddLibrary() doesn't handle
>frameworks ( like qtAddLibrary() does ).  Please add the missing lines
>and send me a patch.

Building qwt 6.1 failed linking the designer plugin (because of
qwtAddLibrary()) with similar linker errors as described in my first
email; applying my patch fixed building/linking/installing.
(Continue reading)

Uwe Rathmann | 5 Feb 08:34 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

Hi Ed,

> I have done nothing with Qt5 yet:  any idea what they did differently that
> they don't need the function any more that qwt can copy?

The functions were made for internal usage of Qt. As Qt5 is completely 
re-modularized they don't make much sense anymore.

>> [ ... using the installed qwtfunctions.pri in qwtpolar ]
>
> I'll see if I can figure anything out... Do you know if that behavior is
> this true on non-mac platforms too?

The same on all platforms.

> The patch above is basically the same as the first email, but for
> completeness, diff output is:

There is already a line that deals with linkage on the Mac:

mac:LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX}_debug

I would expect, that it overwrites LINKAGE and the commands of your 
patch have no effect, when building debug_and_release ?

>> PS2: Do you have Mac with a retina display ?
>
> Yes!

In the last days of Qt 5.0.0 development a new feature was added 
(Continue reading)

Tilman Skobowsky | 5 Feb 13:47 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

Hi Uwe, hi Ed,


I'm also working on some Mac related issues. 

The problem with this kind of LINKAGE statement ist, that it doesn't take into account if the library was linked as framework, which is why the naming gets wrong. The code in qwtfunctions.prf was copied from the Qt function and Uwe removed the parts that deal with using qwt as Mac framework.

I have a patch for 6.0.x in the queue but I haven't had enough time to test everything and post it yet. Right now I'm at work and I don't have access to my private computer where I made the changes. If you're willing to wait until tonight, I will post the DIFF as is, so either one of you can look at the changes and take over parts of it.


Tilman

There is already a line that deals with linkage on the Mac:

mac:LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX}_debug

I would expect, that it overwrites LINKAGE and the commands of your 
patch have no effect, when building debug_and_release ?


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
qwt-interest mailing list
qwt-interest <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qwt-interest
Skobowsky Tilman | 5 Feb 23:26 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

Hi Uwe & Ed,


now that I'm home, I found a little bit of time to check things out and provide a patch for revision 1673 of trunk:
What I did was checking out via
svn checkout svn://svn.code.sf.net/p/qwt/code/trunk/qwt

as described on the qwt web page. After that, I did my patches and created a 'svn diff' (via Qt-Creator, which does the nice color formatting, that hopefully will survive the mailing list manager). With these changes, I could do the following on my Mac (10.6.x with Qt 4.8.4) without getting any errors:

qmake -spec macx-g++ qwt.pro
make
sudo make install

I will check on building my project later. I will also check on building qwt as static lib. I prefer to build release apps statically linked because deploying Mac apps usually means including all the frameworks, which results in larger App files. This also means that am thinking of a way to specify configuration options for qwt without editing the qwtconfig.pri file. (I haven't figured out if and how that would be possible)


HTH
Tilman



Index: qwtbuild.pri =================================================================== --- qwtbuild.pri (Revision 1673) +++ qwtbuild.pri (Arbeitskopie) <at> <at> -30,6 +30,13 <at> <at> CONFIG += debug_and_release CONFIG += build_all } +else:macx { + # On Mac OS X you can easily mix release and debug libraries, when using + # frameworks, so as default: do both. + + CONFIG += debug_and_release + CONFIG += build_all +} else { CONFIG += debug Index: qwtfunctions.pri =================================================================== --- qwtfunctions.pri (Revision 1673) +++ qwtfunctions.pri (Arbeitskopie) <at> <at> -36,14 +36,25 <at> <at> unset(LINKAGE) - if(!debug_and_release|build_pass):CONFIG(debug, debug|release) { - win32:LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX}d - mac:LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX}_debug + static { + LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX} + } else { + mac { + CONFIG(qt_framework, qt_framework|qt_no_framework) { #forced + LINKAGE = -framework $${LIB_NAME}$${QT_LIBINFIX} + } + } } - isEmpty(LINKAGE):LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX} + isEmpty(LINKAGE) { + if(!debug_and_release|build_pass):CONFIG(debug, debug|release) { + win32:LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX}d + mac:LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX}_debug + } + isEmpty(LINKAGE):LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX} + } - !isEmpty(QMAKE_LSB) { + !isEmpty(QMAKE_LSB) { QMAKE_LFLAGS *= --lsb-shared-libs=$${LIB_NAME}$${QT_LIBINFIX} }

Hi Uwe, hi Ed,


I'm also working on some Mac related issues. 

The problem with this kind of LINKAGE statement ist, that it doesn't take into account if the library was linked as framework, which is why the naming gets wrong. The code in qwtfunctions.prf was copied from the Qt function and Uwe removed the parts that deal with using qwt as Mac framework.

I have a patch for 6.0.x in the queue but I haven't had enough time to test everything and post it yet. Right now I'm at work and I don't have access to my private computer where I made the changes. If you're willing to wait until tonight, I will post the DIFF as is, so either one of you can look at the changes and take over parts of it.


Tilman

There is already a line that deals with linkage on the Mac:

mac:LINKAGE = -l$${LIB_NAME}$${QT_LIBINFIX}_debug

I would expect, that it overwrites LINKAGE and the commands of your 
patch have no effect, when building debug_and_release ?


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb_______________________________________________
qwt-interest mailing list
qwt-interest <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qwt-interest

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
qwt-interest mailing list
qwt-interest <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qwt-interest
Uwe Rathmann | 6 Feb 11:31 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

Hi Tilman,

thanks for your patch.

> as described on the qwt web page. After that, I did my patches and
> created a 'svn diff' (via Qt-Creator, which does the nice color
> formatting, that hopefully will survive the mailing list manager).

Well a naked patch attached without tags would be better. For loading it 
into a tool like meld or applying it these tags are not helpful.

> [ debug_and_release ... ]

Probably on all platforms beside Windows it is possible to mix release
and debug libraries. That's why there is a good reason to do it special
on Windows, but there I don't s a good one for the Mac.

The default setting on all other systems should be release only. As
using suffixes for debug libraries ( _debug ) is quite uncommon in UNIX
environments it is more likely, that Qwt would be built twice and
installed into different directories.

( By the way: the only reason why debug was set in SVN was because this
is the setting I'm using for Qwt development. As I have a new system
now, where rebuilding Qwt can be done very fast I changed it to release. )

> LINKAGE = -framework $${LIB_NAME}$${QT_LIBINFIX}

This should be the interesting page - but I changed the condition to
depend on QwtFramework, what is configured in qwtconfig.pri. The default
setting is to depend on qt_framework, but it could be different.

Please check the modified pro/pri files on your systems. Building
applications with "CONFIG += qwt" would be very interesting too.

> I will also check on building qwt as static lib. I prefer to build
> release apps statically linked because deploying Mac apps usually
> means including all the frameworks, which results in larger App
> files.

Simply disable QwtDll in qwtconfig.pri

> This also means that am thinking of a way to specify
> configuration options for qwt without editing the qwtconfig.pri file.

How is this is related to static linkage ?

Uwe

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
Tilman Skobowsky | 7 Feb 00:50 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

Hi Uwe,

> Well a naked patch attached without tags would be better. For loading it 
> into a tool like meld or applying it these tags are not helpful.

Do you have a reference on how that should look? And/or which 'svn diff' parameters to use?  (I'm not that used
to work with diffs due to the fact that we don't really use "diff" at work...)

>> [ debug_and_release ... ]
> 
> Probably on all platforms beside Windows it is possible to mix release
> and debug libraries. That's why there is a good reason to do it special
> on Windows, but there I don't s a good one for the Mac.

There are good reasons to do this on the Mac in a single build though...

> The default setting on all other systems should be release only. As
> using suffixes for debug libraries ( _debug ) is quite uncommon in UNIX
> environments it is more likely, that Qwt would be built twice and
> installed into different directories.

...but I have to go into some details here (hoping, that I don't tell you a lot of things you already know)

In general, most Mac applications make use of so called frameworks. Frameworks bundle the actual library
with optional header files and an optional debug version of the library, whose name is the same as the
libraries name appended by "_debug". (*blink*) The nice part about the "_debug" version is that you can
optionally use them when debugging the code i.e. with Qt Creator or XCode (the native IDE for Mac OS X). So
when the framework bundle provides a debug version, it will be taken, if not, it will use the non debug
version as fallback automatically (*blink*). Using the debug version allows source code stepping into
the library code with the debugger, which of course is very handy sometimes.
As a matter of fact, the Qt library installer for Mac (up until 4.8.x) installed the Qt Frameworks
containing the release libs. An optional installer adds the debug libraries to the already installed Qt
frameworks. 

Second: Mac applications are deployed as application bundle.The bundle is really a folder that is shown as
if it were a single file. More important, the application bundle contains all libraries used by the
application within the bundle. As a result, the application can be installed by simply copying the
application "file" (folder) to any place – without an installer (windows) or the need to first install
other packages (*nix).
Starting at around 4.5 or so, Qt includes a tool called "macdeployqt" that takes the work-in-progress
developement application, collects the referenced libraries / frameworks and puts them all into a
release application bundle (converting absolute references to libs / frameworks to relative
references within the bundle) – which is very, very handy.

Ok, the one drawback of putting all libraries into the application bundle is, that you can't reuse the same
libraries for various applications, so there is a lot of duplication of libraries. On the other hand, this
way you will avoid the DLL-hell known to the Windows world, since you never have the problem of using the
wrong version of a library. And last not least, it is very easy to install software on a Mac.

For some more info on Framworks see around here, if your're really interested in... (or don't bother)

	https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html#//apple_ref/doc/uid/20002253-BAJEJJAB

> Please check the modified pro/pri files on your systems. Building
> applications with "CONFIG += qwt" would be very interesting too.

I did check with my project, which uses the above line. BTW: I  set QMAKEFEATURES with the following line:

	qmake -set QMAKEFEATURES /usr/local/qwt-6.1.0-svn/features

before I was able to use "CONFIG+=qwt" (I just repeat this for people like me: it took me a while to figure this
one out...)

There is one problem left: The samples are compiled properly, but they can't be run directly because the Qwt
framework is not found by the dynamic library loader (see "man dyld" on a Mac). The reason for this lies in
the fact that in the final executable, the reference to the qwt.framework is relative to some known
locations for frameworks. But since "make install" does not put the qwt.framwork to one of this "well
known" places (like "/Library/Framwork" which is the place, where the official Qt installer places its
frameworks) we are somewhat stuck here.

For now there are two solutions to this problem:
1.	You must either set "DYLD_FRAMEWORK_PATH=/usr/local/qwt-6.1.0-svn/lib/"
2.	You must create the following symlink:
	
		ln -s /usr/local/qwt-6.1.0-svn/lib/qwt.framework/ /Library/Frameworks/qwt.framework

The first solution works only while you work from command line. There is a way to set this on startup, but
don't bother, take the second solution. The second solution puts the link to the qwt.framework to a "well
known" place where it can be found (by any application and "macdeployqt") which is what I did on my
development machine.

I do have an idea on how to circumvent this by making the "make install"ed version of qwt.framework use
absolute paths (for the library itself, so the reference in the app using qwt is absolute as well... don't
bother if you don't understand what I'm writing here). But I have to check if "macdeployqt" is still able to
bundle the app correctly...

>> I will also check on building qwt as static lib. I prefer to build
>> release apps statically linked because deploying Mac apps usually
>> means including all the frameworks, which results in larger App
>> files.
> 
> Simply disable QwtDll in qwtconfig.pri
> 
>> This also means that am thinking of a way to specify
>> configuration options for qwt without editing the qwtconfig.pri file.
> 
> How is this is related to static linkage ?

I'll get into this in a future post...

Tilman

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
Uwe Rathmann | 7 Feb 09:03 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

Hi Tilman,

>> Probably on all platforms beside Windows it is possible to mix
>> release and debug libraries. That's why there is a good reason to
>> do it special on Windows, but there I don't s a good one for the
>> Mac.
>
> There are good reasons to do this on the Mac in a single build
> though...

But even after your explanations I still don't see why these reasons are
special for the Mac - or frameworks.

When you argue that debug_and_release should be the default setting the
arguments will be valid on all systems. The same arguments would
probably result to the requirement of building static and shared libs in
one build.

But I would expect, that the majority of the users doesn't want to debug
Qwt code. Those who want this can build debug libs and should be free to
decide whether to do it in one or two build steps.

This conforms with what you have written about the Qt installer on the
Mac: default is release only, installing debug is optionally.

( By the way:
http://doc-snapshot.qt-project.org/qtifw-1.2/ifw-overview.html. For the
future I would like to have on the option of offering installable
packages. When you - or someone else - wants to work on this ... )

> The samples are compiled properly, ...

Basically for debug_and_release they are compiled twice - where the
second build overwrites the first one.

This makes no sense at all, but I don't see a good solution beside
having different settings for lib and applications/plugins.

> but they can't be run directly because the Qwt framework is not found
> by the dynamic library loader (see "man dyld" on a Mac).

Installing Qwt doesn't necessarily mean, that a user on a system always
wants to work with this version of Qwt ( f.e. I have 10 different
versions of Qt on my system )- not to forget, that there might be more
than one user.

It is up to the user/admin to setup a working environment. This might be
supported in the future by a binary installer ( f.e. offering to set
QMAKEFEATURES ), but modifications of the application environment should
never be done from a "make install" of a lib.

> set "DYLD_FRAMEWORK_PATH=/usr/local/qwt-6.1.0-svn/lib/"

For shared libs on Linux systems you have the following options:

1) setting LD_LIBRARY_PATH
2) adding a path to /etc/ld.so.conf
3) compile a run-time search path into the application ( QMAKE_RPATH )

I would expect to find comparable options for frameworks on the Mac.

Uwe

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
Clarkson, Edward C. | 7 Feb 16:23 2013
Picon

RE: Mac qwt/qwtpolar build/install suggestions

> > set "DYLD_FRAMEWORK_PATH=/usr/local/qwt-6.1.0-svn/lib/"
> 
> For shared libs on Linux systems you have the following options:
> 
> 1) setting LD_LIBRARY_PATH
> 2) adding a path to /etc/ld.so.conf
> 3) compile a run-time search path into the application ( QMAKE_RPATH )
> 
> I would expect to find comparable options for frameworks on the Mac.

I expected that too, but it's not true:  #2 does not exist.  See e.g., http://stackoverflow.com/questions/1451047/ldconfig-for-mac-os-x

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
David Flogeras | 7 Feb 16:31 2013

Re: Mac qwt/qwtpolar build/install suggestions

When I deal with OSX, I have found that I can make #3 happen by 
appending the following to qwtconfig.pri

QMAKE_LFLAGS_SONAME  = -Wl,-install_name,/path/to/my/lib/

(And the final slash is required)

This way when you link other apps/libraries to the qwt dylib, they 
remember it's location without needing DYLD_LIBRARY_PATH.

AFAIK this is OSX specific and will have to be handled if you do more 
than one platform.

For diagnosing, you can use the OSX tool 'otool' which is roughly 
similar to readelf on Linux.

HTH
Dave

On 02/07/2013 11:23 AM, Clarkson, Edward C. wrote:
>>> set "DYLD_FRAMEWORK_PATH=/usr/local/qwt-6.1.0-svn/lib/"
>>
>> For shared libs on Linux systems you have the following options:
>>
>> 1) setting LD_LIBRARY_PATH
>> 2) adding a path to /etc/ld.so.conf
>> 3) compile a run-time search path into the application ( QMAKE_RPATH )
>>
>> I would expect to find comparable options for frameworks on the Mac.
>
> I expected that too, but it's not true:  #2 does not exist.  See e.g., http://stackoverflow.com/questions/1451047/ldconfig-for-mac-os-x
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> qwt-interest mailing list
> qwt-interest <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qwt-interest
>

--

-- 
The information contained in this e-mail may contain confidential 
information intended for a specific individual and purpose. The 
information is private and is legally protected by law. If you are not 
the intended recipient, you are hereby notified that any disclosure, 
copying, distribution or the taking of any action in reliance on the 
comments of this information is strictly prohibited. If you have 
received this communication in error, please notify the sender 
immediately by telephone or return e-mail.

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
Clarkson, Edward C. | 7 Feb 22:25 2013
Picon

Re: Mac qwt/qwtpolar build/install suggestions

On 2/5/13 2:34 AM, "Uwe Rathmann" <Uwe.Rathmann <at> tigertal.de> wrote:

>In the last days of Qt 5.0.0 development a new feature was added
>hectically for these displays. See:
>
>http://qt-project.org/doc/qt-5.0/qtgui/qwindow.html#devicePixelRatio
>
>I copied the way how it is used in QwtPainter::backingStore() from
>checking what was committed together with this new feature.
>
>As f.e. the backing store of the plot canvas - where all plot items are
>painted to - is using it, you should see if it works easily.
>
>Could you please check if the code is correct ?

Do you mean with Qt 5.0?  And 6.1?  In any case, all the 6.1 examples look
fine to me, if that's an adequate test.

My project doesn't compile against 6.1 (several apparent source
incompatibilities identified in an earlier list posting), and I don't even
have 5.0 installed.  HTH,

Ed

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

Gmane