ipe @7.0.14: Please add an application bundle to Applications/MacPorts/

[maehne (Torsten Maehne)]

It would be nice if ipe would install an application bundle to Applications/MacPorts so that it could be started from the Finder. I was able to create a small application bundle (attached), which just contains a symbolic link to /opt/local/bin/ipe, an icon, and an Info.plist file. Unfortunately, I don't have the time to dive deep enough into MacPorts infrastructure to propose a full-fledged patch for the port.

[maehne (Torsten Maehne)]

application bundle for ipe

[maehne (Torsten Maehne)]

I have done some further testing of my application bundle. Unfortunately, my solution does not work perfectly. It works fine as long as the figure does not include any text labels. If I type CMD-L to typeset the text labels with pdflatex, I get the following an error message pops up: "An error occured during the Pdflatex run" "There was an error trying to run Pdflatex". The TeX file is correctly created in ~/.ipe/latexrun/ and compiles without errors when running pdflatex manually.

A similar error was reported on the Ipe-discuss mailing list: ​http://mail.cs.uu.nl/pipermail/ipe-discuss/2011-July/001324.html

Ipe's sources suggest (./src/ipelib/ipeplatform.cpp:303) that it just runs "pdflatex ipetemp.tex". Therefore, pdflatex needs to be found in the PATH. This is the case from the command line, where I have added /usr/texbin to the PATH via ~/.MacOSX/environment.plist. However, the therein defined environment variables don't seem to be respected by applications launched from the Finder. I tried to add the correct PATH as an entry to the Info.plist under the LSEnvironment key, as described in:

​http://www.mactech.com/articles/mactech/Vol.23/23.07/2307MacEnterprise-EnvironmentVariables/index.html ​http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html

However, this does not seem to have any effect.

[maehne (Torsten Maehne)]

I forgot to specify my platform: Mac OS X 10.6.8 (x86_64) with MacPorts 2.0.0 and TeXlive 2010.

[ryandesign (Ryan Carsten Schmidt)]

I've attached a patch to implement this suggestion. Does it look ok to commit?

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[m.thon@…]

It looks reasonable to me, although I have no experience with app-bundles.

[ryandesign (Ryan Carsten Schmidt)]

r81638

[maehne (Torsten Maehne)]

Thanks for the quick reaction on my bug report. I checked the patch. The application launches, but Ipe reported still "There was an error trying to run Pdflatex". Therefore, I digged further. Your patch just adds /opt/local/bin to the PATH. This is probably fine if TeXlive is installed through MacPorts, but I prefer to install MacTeX instead, which offers a better integration with the Mac OS X GUI. MacTeX puts all binariies into /usr/texbin. Therefore, I added it to the PATH in Contents/MacOS/Ipe script. Further, I checked the Contents/Info.plist using the following reference documentation:

​http://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009248-SW1

and especially the documentation about the Launch Services:

​http://developer.apple.com/library/mac/#documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/LSCConcepts.html#//apple_ref/doc/uid/TP30000999-CH202-SW9

I registered the *.ipe, *.eps, *.pdf extensions to be opened by Ipe and provided Icon files for them, which I generated from the file type icons that I found in the ipe-7.0.10-win.zip archive <​http://sourceforge.net/projects/ipe7/files/ipe/>.

I realized that the Application bundle needs to be touched to update its time stamp so that Mac OS X gets aware of the modified Info.plist:

​http://developer.apple.com/library/mac/#documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/LSCConcepts.html%23//apple_ref/doc/uid/TP30000999-CH202-BABEJFCD

Then also the LSEnvironment key works to specify the PATH. Therefore, I could replace the wrapper script again by a symbolic link to /opt/local/bin/ipe.

What does not work so far correctly is the opening of the associated file type: Ipe is launched, but the selected file not opened. The explanation is that Mac OS X does not pass the file name as a command line argument, but sends an "odoc" Apple event. Qt4 provides platform-independent support for this concept:

​http://doc.qt.nokia.com/qq/qq18-macfeatures.html#newevents

The required modifications to the source code seem to be quite straightforward. However, I'm not familiar enough with Ipe's C++/Lua code base to do it myself. The upstream developer Otfried Cheong does not have a Mac to do and test it.

Attached, you can find my current version of the app bundle.

[m.thon@…]

this is currently broken, as:

• 1. the PATH environment variable is insufficient for the Ipe GUI (it does not find pdflatex in /usr/texbin)

possible hack is to use PATH="@PREFIX@/bin:/usr/libexec/path_helper -s | /usr/bin/head -1 | /usr/bin/sed 's/PATH="\(.*\)".*/\1/':$PATH" "@PREFIX@/bin/ipe" in a launcher script. Any better idea?

• 2. the desired behavior (opening associated files with Ipe.app / dropping files to open onto the Ipe.app) does not work

does this need the native support by ipe as outlined above? is there any other workaround (e.g. implementing some sort of droplet / launcher for ipe)?

[maehne (Torsten Maehne)]

Hello, I reuploaded the updated v2 of the dummy application bundle, as it was corrupt. Additionally, there's currently activity upstream to support the "odoc" Apple event in Ipe. The Ipe-7.1.0 Tar ball linked in this feature request ​https://sourceforge.net/apps/mantisbt/ipe7/view.php?id=58 already supports this new functionality. I tested it by adapting the Ipe 7.0.14 Portfile in MacPorts to 7.1.0 and building the application through MacPorts. It works quite well so far.

[maehne (Torsten Maehne)]

Updated application bundle for Ipe

[maehne (Torsten Maehne)]

Updated application bundle for Ipe

[maehne (Torsten Maehne)]

Updated Portfile and patches for Ipe 7.1.0 (yet unreleased so download from an unofficial location)

[m.thon@…]

Ok, so this looks quite promising. However, we should wait for the official release of Ipe 7.1.0 on sourceforge.

@ryan: Using the new app-Portgroup, is it possible to further configure the Info.plist file (to add CFBundleDocumentTypes and LSEnvironment->PATH)? And to add Resources (filetype icons)?

@Maehne: With the upcoming release of Ipe 7.1.0 the patch-files are no longer needed. We only need to specify the required ...LIBS and ...CFLAGS as build.args.

[ryandesign (Ryan Carsten Schmidt)]

Replying to m.thon@…:

@ryan: Using the new app-Portgroup, is it possible to further configure the Info.plist file (to add CFBundleDocumentTypes and LSEnvironment->PATH)? And to add Resources (filetype icons)?

There are no provisions for these things in the app portgroup right now. We could investigate adding such things, but I assumed that no developer would actually go to the trouble of supporting Mac-specific events like odoc without also putting together their own app bundle.

Sorry I have not responded to your earlier comments in this ticket but the effort you're going to here, while clearly valiant, is way above and beyond what I would put into an application bundle in a port, and that's why I haven't had the concentration to attempt to evaluate your work. If ipe wants to offer a first-class experience on Mac OS X, with app icons and document icons and properly responding to Mac events, then those efforts should occur in the ipe source code, not in the portfile. I'm not sure from what you wrote but it sounds like maybe that's the direction you're already moving here?

[m.thon@…]

This is resolved in the port for the new version of ipe (7.1.0).

• odoc event is supported in ipe itself
• The filetype associations and filetype-icons are in the portfiles for now
• The required PATH setting is also handled by the portfiles for now

[maehne (Torsten Maehne)]

Ipe is still at version 7.0.14 in MacPorts. In the meantime, Otfried Cheong released version 7.1.1. Taking into account the previous comments, I have updated the Portfile and support files and provide it in form of a patch. I had to fix to some compiler errors in 7.1.1 (patch-ipe-src-7.1.1.diff), which I have reported to Otfried Cheong (​Issue #89). I also improved the Info.plist of the application bundle to register Ipe as editor for IPE, EPS, and PDF files. For the latte two file formats, Ipe is just registered as an alternative editor.

I have tested the new port successfully on Mac OS X Lion (10.7.2) with Xcode 4.2.

[maehne (Torsten Maehne)]

Patch to update Ipe port from 7.0.14 to 7.1.1

[m.thon@…]

I committed an update ticket for ipe-7.1.1 with Portfile patch (#31153) that resolves this tickets issues a couple of weeks ago (but it has not been committed yet). I just checked and see that indeed ipe does not compile with clang. So I updated the Portfile to use llvm-gcc-4.2 instead for now, which works fine.

[maehne (Torsten Maehne)]

Please check out my patch. It fixes Ipe in a way that it compiles with clang. My ​issue report #89 to Otfried Cheong details, why clang fails to compile Ipe: a static C array is declared with an integer variable used to specify its size. This is not legal C++ and shouldn't compile.

[m.thon@…]

@Torsten.Maehne: Yes, I saw that your patch fixes the compilation issue. I personally would wait until this is fixed upstream in the next ipe version, and use llvm-gcc4.2 to compile ipe in the meantime (saves patch files). What do you think?

[maehne (Torsten Maehne)]

@m.thon: Thank you for your quick responses!

Usually, I would agree with you that this issue should be fixed upstream. Hence, I reported the issue. However, in this case I'm not sure if llvm-gcc4.2 is generating correct code even though it doesn't report an error. Declaring a C array with an integer variable specifying its size leads to undefined behavior. Therefore, I would prefer the patch to be applied to the Ipe 7.1.1 source code. The patch can be removed once it is fixed upstream.

[m.thon@…]

@Torsten.Maehne: Ok. I modified the Portfile in #31153 accordingly. Please have a look. I think this should also include most of your suggestions from this ticket. BTW, I didn't include your change in ipepswriter.h (class Font -> struct Font) though. Was that relevant?

And, I have no commit rights, so I have no idea when this will be committed.

[maehne (Torsten Maehne)]

@m.thon: Sorry, for the late reply. I have reviewed your Portfile in #31153. I have a couple of remarks:

• The *.ico files for the different file types are optional. My most recent Portfile, generates a sole ipe.icns file from ipe/icons/ipe.png.
• The LSEnvironment section in Info.plist can be skipped if the shell wrapper to call the ipe executable is used. Finally, I prefer the solution of the wrapper script, as it permits to handle the PATH variable in a more flexible way. To this end, my updates to the ipe.in wrapper adds /usr/texbin in front of ${prefix}/bin to the PATH if it is present (i.e., MacTeX is installed).
• The patch to ipepswriter.h changes the predeclaration from class Font to struct Font, which avoids a compiler warning and has also been reported in upstream ​ticket #89.

I attach an archive of the ipe port directory to show you the final result as well as a patch from port ipe 7.0.14 to ipe 7.1.1. I think you will agree that it makes the port more compact.

[maehne (Torsten Maehne)]

Tar archive of port for ipe 7.1.1

[maehne (Torsten Maehne)]

Patch to update port ipe from 7.0.14 to 7.1.1

[m.thon@…]

Ok, so all of these are really minor things, and I don't know if there is a right or wrong about them. My take on them:

• I agree to using the ipe icon for ipe-related files, too -- for the sake of simplicity (although I did kind of like the individual icons. They were part of an earlier ipe release) (changing that in #31153 now). Perhaps Otfried or someone could provide some nice icons in a future release)
• I suggest using LSEnvironment to set the PATH in the Info.plist -- again for the sake of simplicity. Also, that is the usual Mac way of doing it, or not? Although, I really think it makes very little difference. In any case you would still need to
• I don't see the point of including a patch just to avoid a compiler warning.

[maehne (Torsten Maehne)]

Thanks for your quick reaction. I agree, the individual icons for the different file formats are nice. In the second app bundle that I proposed, even an adapted *.icns file for the *.ipe format is included. Indeed, it would be nice if the icons would be updated in a future release to use some higher resolution. So, feel free to use them. :-)

I agree, the LSEnvironment key is the preferred method to set the PATH in an app bundle. However, I didn't want to hardcode into it the whole path. $prefix/bin should be most probably always added in front of the default patch. If MacTeX is installed, additionally /usr/texbin should be prepended to the PATH. For me, it was easier to do this with the wrapper script, as I'm not very familiar with Tcl. Maybe, you want to take a try to substitute the PATH in Info.plist after installation of the app bundle? It is important that the LaTeX binaries are found by Ipe. Otherwise, all text labels will fail to render correctly.

Feel free to leave out the patch which prevents the compiler warning.

Thank you for maintaining the port! Ipe is a very useful tool for me.

[m.thon@…]

Replying to Torsten.Maehne@…:

Thanks for your quick reaction. I agree, the individual icons for the different file formats are nice. In the second app bundle that I proposed, even an adapted *.icns file for the *.ipe format is included. Indeed, it would be nice if the icons would be updated in a future release to use some higher resolution. So, feel free to use them. :-)

I think I was actually using the same icons, and based the Portfile update on your app bundle. I just provided them in a different format to save space. Anyhow, this is cosmetics, and nice icons should really be provided by ipe and not by MacPorts. So let's stick to the default ipe.png for now.

I agree, the LSEnvironment key is the preferred method to set the PATH in an app bundle. However, I didn't want to hardcode into it the whole path. $prefix/bin should be most probably always added in front of the default patch. If MacTeX is installed, additionally /usr/texbin should be prepended to the PATH. For me, it was easier to do this with the wrapper script, as I'm not very familiar with Tcl. Maybe, you want to take a try to substitute the PATH in Info.plist after installation of the app bundle? It is important that the LaTeX binaries are found by Ipe. Otherwise, all text labels will fail to render correctly.

I am not sure if this is really correct, but I think for apps on OSX no default PATH is set (I tried your wrapper script, but the "open" command is not found when accessing the help). Therefore, the full PATH has to be set anyway. I now added the standard PATH to the entry in the Info.plist, which now sets PATH to @PREFIX@/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/usr/local/texbin:/usr/local/bin. @PREFIX@ is then substituted by the correct MacPorts prefix. It doesn't hurt to add directories that don't exist to the PATH.

Ipe is a very useful tool for me.

Yeah! I've also been using it for all my LaTeX diagrams for several years :-)

P.S.: I hope someone closes this ticket sometime soon...

[maehne (Torsten Maehne)]

Replying to m.thon@…:

Replying to Torsten.Maehne@…:

Thanks for your quick reaction. I agree, the individual icons for the different file formats are nice. In the second app bundle that I proposed, even an adapted *.icns file for the *.ipe format is included. Indeed, it would be nice if the icons would be updated in a future release to use some higher resolution. So, feel free to use them. :-)

I think I was actually using the same icons, and based the Portfile update on your app bundle. I just provided them in a different format to save space. Anyhow, this is cosmetics, and nice icons should really be provided by ipe and not by MacPorts. So let's stick to the default ipe.png for now.

I completely agree.

I agree, the LSEnvironment key is the preferred method to set the PATH in an app bundle. However, I didn't want to hardcode into it the whole path. $prefix/bin should be most probably always added in front of the default patch. If MacTeX is installed, additionally /usr/texbin should be prepended to the PATH. For me, it was easier to do this with the wrapper script, as I'm not very familiar with Tcl. Maybe, you want to take a try to substitute the PATH in Info.plist after installation of the app bundle? It is important that the LaTeX binaries are found by Ipe. Otherwise, all text labels will fail to render correctly.

I am not sure if this is really correct, but I think for apps on OSX no default PATH is set (I tried your wrapper script, but the "open" command is not found when accessing the help). Therefore, the full PATH has to be set anyway. I now added the standard PATH to the entry in the Info.plist, which now sets PATH to @PREFIX@/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/usr/local/texbin:/usr/local/bin. @PREFIX@ is then substituted by the correct MacPorts prefix. It doesn't hurt to add directories that don't exist to the PATH.

I agree. However, to avoid shadowing of a MacTeX install, which is usually more up-to-date than the MacPorts TeXlive version, it is preferable to have /usr/texbin added in front of @PREFIX@/bin, as described in the ​MacTeX FAQ. I therefore modified my Info.plist.in as follows:

        <key>LSEnvironment</key>
        <dict>
                <key>PATH</key>
                <string>/usr/texbin:@PREFIX@/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin</string>
        </dict>

Additionally, I would mention the license of Ipe in the Portfile: GPL-3. I attach the two modified to this bug report to not cause confusion in #31153. You might mention there that the ipe.in wrapper isn't needed anymore.

Ipe is a very useful tool for me.

Yeah! I've also been using it for all my LaTeX diagrams for several years :-)

P.S.: I hope someone closes this ticket sometime soon...

I hope this, too!

[maehne (Torsten Maehne)]

Proposed Portfile diff for #31153

[maehne (Torsten Maehne)]

Proposed Info.plist.in patch for #31153

[drkp (Dan Ports)]

Superseded by #32926