[texworks] Updated builds of TeXworks for OS X

[Charlie Sharpsteen]

On Mon, May 16, 2011 at 11:07 PM, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> thanks for your description of building universal binaries. I think,
> things are beginning to add up in my head ;).
>
> On 2011-05-16 02:12, Charlie Sharpsteen wrote:
>> [snip]
>> Luckily, the TeXworks dependencies build into universal binaries just
>> fine using method #1. Qt has special configure flags that handle
>> universal binary creation. Thank yourselves for having such a short
>> dependency list as it makes this whole operation much easier.  I may
>> look into adding custom Homebrew formulae for `qt.rb` and
>> `hunspell.rb` alongside `poppler.rb` that take care of building
>> universal binaries.
>
> Doesn't qt.rb have a "universal" flag? From its formula:
> ['--universal', "Build both x86_64 and x86 architectures."]
>
> It doesn't seem to build ppc binaries, though. Anyway, I could imagine
> that patches for this might also be of interest to the upstream repo...

Homebrew's formula for Qt does have a `--universal` flag, but this is
just a trigger that causes qt.rb to pass the appropriate flags for
building `i386` and `x86_64` to the Qt configure script.
Unfortunately, PPC additions aren't welcome in the main Homebrew
repository.  This is because the project was started well after Apple
switched to Intel hardware and there are only 4 people with commit
access to the central repository---not supporting PPC is a line that
had to be drawn in order to keep the workload manageable.

The Homebrew philosophy is that if someone doesn't like the Homebrew
philosophy it should be trivial for them to fork the project and do
whatever they please.  There is a fork that maintains PPC support:

    https://github.com/sceaga/homebrew/commits/powerpc

But I don't know how active it is.


>>>> Current issues with the builds:
>>>>
>>>>   - If anyone is feeling artistic, it would be nice to come up with a
>>>> snazzy background image for the Drag N' Drop installer.
>>> I'm not feeling particularly artistic, but what kind of image are we
>>> talking about? Is there a webpage with some screenshots, maybe?
>> Wolfgang Schuster provided an excellent example of the desired effect.
>> It looks like we will need:
>>
>>   1. A PNG file that contains the background image.
>>
>>   2. A DS_Store file that tells OS X how to position the directory
>> contents and points to the PNG file as a background image.
>>
>> If someone comes up with a nice background, I could probably create
>> the DS_Store file.
>
> Thanks. I'll see if I can wrap something up, but I'm not going to have
> much time in the foreseeable future. So if someone else has a go at it I
> wouldn't mind ;).
>
>>>>   - I noticed that the last official Mac build includes the following
>>>> Qt plugins:
>>>>
>>>>     * accessible
>>>>     * codecs
>>>>     * graphicssystems
>>>>     * imageformats
>>>>     * script
>>>>
>>>>     Currently, my builds don't contain any of these plugins and seem
>>>> to run fine (given extremely limited testing). Are any of these
>>>> plugins necessary?
>>
>>> 2) Do pdfs with embedded .png or .jpg files display correctly?
>>> 3) Can you drag&drop image files (e.g., .png or .jpg) into the editor
>>> and they get converted to \includegraphics{...} commands automatically?
>>>
>>> If 2 and 3 work, then "imageformats" (and perhaps "graphicssystems") are
>>> taken care of.
>> All images seem to display correctly. Drag and drop of PNG files
>> works. However, JPEG drag and drop causes TeXworks to open the JPEG
>> file for editing instead of inserting \includgraphics{...}. So it
>> looks like I may need to add some of the graphics plugins.
>
> Hm...
> You could try to see what QImageReader::supportedImageFormats() gives
> (you'll also need to add "#include <QImageReader>"; see
> http://doc.trolltech.com/4.7/qimagereader.html#supportedImageFormats) at
> run time.
>
> Other than that, I found
> http://doc.trolltech.com/4.7/deployment-mac.html#the-mac-deployment-tool, which
> states (among other things) that Qt's default deployment tool follows
> the "Image format plugins are always deployed" policy. If CMake is not
> using said macdeployqt, I guess you have to convince it to deploy those
> image format plugins itself...
>
> HTH
> Stefan

I think I may address the plugin situation by importing this CMake
module into the project:

    https://github.com/KDAB/Charm/blob/master/CMake/DeployQt4.cmake

It provides a wrapper on top of the `fixup_bundle` function that takes
care of importing plugins from the main Qt libraries.

-Charlie