pcp
[Top] [All Lists]

Re: [pcp] Qt 4.7: moving to new help format

To: Max Matveev <makc@xxxxxxxxx>
Subject: Re: [pcp] Qt 4.7: moving to new help format
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 7 Dec 2010 20:59:46 +1100 (EST)
Cc: pcp@xxxxxxxxxxx
In-reply-to: <19708.54632.323598.804331@xxxxxxxxxxxx>
----- "Max Matveev" <makc@xxxxxxxxx> wrote:

> On Fri, 3 Dec 2010 11:21:56 +1100 (EST), nathans  wrote:
> 
>  >> The reason I'm asking is because trolls removed support for adp
>  >> from Qt 4.7 - I've discovered that when I've tried to compile
>  >> pcp-gui against that version and couldn't find qassistantclient
>  >> headers.  There is a backport floating around the net but it
> looks
>  >> like the direction trolls prefer people to take is to switch.
> 
>  nathans> Should be no major issues there, though do you know which
> qt
>  nathans> release this first appeared in?  From a quick google
> search,
>  nathans> looks like qt4.4.
> 
> According to
> http://doc.trolltech.com/4.4/qt4-4-intro.html#improved-help-system it
> was indeed 4.4 which introduced new help format. Unfortunately git on
> qt.nokia.com only goes as far as 4.5, so it's hard to tell precisely
> when did the switch occured.
> 
>  nathans> Which means, pcp-gui wont compile on RHEL5 anymore, and
> some
>  nathans> other distros, I guess... not ideal, unless we can make it
>  nathans> conditional (I would unconditionally ditch the old-school
>  nathans> format stuff still, though make new stuff on/off...?).
> 
> It's possible to make it conditional but it does mean that we'll have
> to maintain two sets of XML files - the format is different. Also

Well, alternative is "new" format or none, which I think would be OK,
since most people would be post 4.4 now.

> there may be some differences in the list of html files shipped
> altough I'm almost certain the two lists will be close.

I would recommend not trying to keep old format arounds.

>  >> I've converted pcpdoc.adp to qch/qhc and compiled the help
> manually -
>  >> after a bit of massage QAssistant displays the help if launched
> from
>  >> the command line (trying to use pmchart's Help>Manual does not
> work
>  >> on Darwin).
> 
>  nathans> Any idea why that is?  (missing library?)  It should work.
> 
> Two reasons:
> 
> 1. Assistant_adp is not packaged with pcp-gui - unless Qt was
>    installed explicitly there will be no viewer.
> 
> 2. Even if the viewer is installed the mere fact of including qt.conf
>    into the app bundle (which I've added to deal with plugins issues)
>    changes the default path from /Developer/Tools/Qt to
>    /Application/pmchart.app/Contents/bin which is obviously wrong.
> 
> Fixing #2 is easy - just add
> 
> Binaries = /Developer/Tools/Qt
> 
> to /Applications/pmchart.app/Content/Resources/qt.conf and it'll make
> Qt look in the "right" place. This can be done manually on the
> already

Hmmm, for any people needing online help, this isn't likely feasible.

> installed pcp-gui. Packaging QtAssistant_adp is a bit trickier and
> will require additional Qt frameworks to be added to the pcp-gui
> package.

Sounds like we need to do that (maybe as part of this transition?).

>  >> I can wrap the whole thing into makefile if this is useful.
>  >> BTW, it does open a question about external dependencies - I
>  >> definitely didn't include QAssistant into the package when I was
>  >> messing with frameworks on Darwin.
> 
>  nathans> Hmmm, thats not good.  Works on Windows and Linux... should
> be doable
>  nathans> on Mac... pretty sure it did at one point in the past,
> anyway.  We'll
>  nathans> need that even with qch format help, right?
> 
> Yes, it's just the question of which one will it be - Assistant or
> Assistant_adp (if we're to support platforms which ship with Qt <
> 4.4)

I think we should try to keep compilation here (for now, anyway)
but I'm OK with no online help for those few users.

>  >> The other question is the move to Qt 4.7: it now has two versions
> -
>  >> Carbon and Cocoa on Darwin, Cocoa even has 64 bit libraries which,
> in
>  >> theory, would allow for 64 bit pcp-gui. Any preferences from mac
> pcp
>  >> users for timing of the switch and the GUI technology?
> 
>  nathans> We already do two builds of pcp-gui, one on Snow Leapord
>  nathans> which uses the 64 bit qt
> 
> I thought that Carbon only came with 32 bit binaries and Cocoa is
> only
> available on Qt 4.7.

I think it was 4.6 that introduced this (it was 4.6 that supported
Snow Leapord anyway, which AIUI is 64 bit only?  This was the point
at which all hell broke loose here anyway, and people who upgraded
their Macs to Snow Leopard had now pcp-gui for some time... :(  I'm
assuming this was all 64 bit fallout, and 4.6 seemed to fix that).

>  nathans> ... we should improve the build to add on i386/x86_64
>  nathans> to the generated dmg filenames though, that'd be useful
> (manual atm).
> 
> Sorry, I'm not sure I'm following you here. If we move to Cocoa
> version then i386/x86_64 switch will happen automatically, if we stay
> with Carbon then, AFAIK, we're stuck with i386.

Right - the x86_64 dmg file on oss is compiled on Snow Leopard, the
i386 dmg is compiled on 10.4 (IIRC), 32 bit.

cheers.

-- 
Nathan

<Prev in Thread] Current Thread [Next in Thread>