posted by Eugenia Loli on Wed 9th Apr 2003 03:30 UTC

"Fink Interview, Part II"
4. How about offering more "integrated" ports to OSX? For example, when you port Gnome or KDE and their apps, how about using by default OSX fonts and themes that resemble that of native OSX's? Also, what about drag-n-drop and copy/paste between native and X apps?

Max Horn: These two examples are actually to radically different things :-)
As to making Gnome/KDE use default OSX fonts and themes, we have the applesystemfonts package which makes all OSX font available to X11. Also, Apple's X11 does the same for you. If you use Apple's X11 and their quartzwm window manager, window borders are in the aqua look. We also have the mosfet-liquid and xliquid-gtk2 packages for KDE/GTK2 which more or less provide an Aqua look-alike. But both are optional, and we currently have no plans to make them a required default.

Copy/paste integration is not in Fink's, but in XFree86's domain, and at least for text has been reality for a long time - see here. That document is slightly outdated though, as it doesn't mention Apple's X11. There, you can copy text via Cmd-C / Edit-Copy. For some reasons, Cmd-V / Edit-Paste doesn't work, though. So to paste text, you have to do it the X11 way with the middle mouse button (if you only have one, pressing Alt/Option while clicking will do the trick).

Making drag&drop work between OS X and KDE/Gnome would be quite a mammoth task and is definitely out of scope for Fink. That's more something for the KDE/Gnome/XFree86/Apple X11 teams to worry about .

5. What are the next plans for the Fink project. What new features or advancements are you cooking for the Mac users?

Max Horn: Besides packaging more and more stuff, and keeping our existing 2333 packages (last count) up-to-date and functional, you mean? :-)

For one thing, we are working towards the 0.5.2 binary release, which is hopefully going to be released soon (CVS has already been tagged, but QA and some other things still need time). I already mentioned it will feature FinkCommander, and more binary packages than ever. Overall I believe it will be the best Fink release so far, as the team (and Dave Morrison in particular) has worked hard to fix bugs and resolve certain issues that troubled previous binary releases.

There are various other things in the planning, for example a revamped dependency engine (a very complicated task), adding so-called "variants" to the build engine, providing our own source file repository (a joined effort with the OpenDarwin project), and more. Stay tuned.

6. Do you have any plans on providing some application binaries that are G4/Altivec-optimized?

Max Horn: Currently, we do little in that direction, mostly due to our policy that ask for binaries to be identical (as far as possible) on all systems. The motivation for that is to make maintenance possible for us; plus it's of course important that binaries from the binary distribution work on all systems. Providing optimized binaries has not been high on our task list for that reason. In fact, there are quite some packages out there which are only built with minimal optimization (-O) and even with debug information (-g). Usually because it's the default setting for many packages.

There are exception, the atlas package for example (a scientific package with highly optimized linear algebra functions) optimizes itself to the system it is built on. It allows you to build with Altivec support enabled. Another package which is highly optimized (although not Altivec specific) is KDE, which Benjamin Reeds tweaked so much that now it's many times faster than its first version on OS X were.

Right now, there are still quite some G3 users out there, for whom an Altivec-only package would be annoying. OTOH, maintaining 2 versions of a package (one with Altivec, one without) can be tedious (or even 4 or 8, if you have also the choice between optional X11and SSL support). We have been planning to add support for "variants" to the Fink .info format for some time now, which would make it very easy to provide special Altivec enabled versions of a package when building on a G4.

Finally, one thing one shouldn't forget: optimizing something for Altivec is not just a matter of throwing in a "-faltivec" switch. The Apple GCC currently has little ability (any?) to automatically vectorize operations. Thus, code has to be hand rolled to take advantage of it, and that means it's really the job of the upstream maintainer, and not ours, to do it. We distribute software, we don't make it (except for the fink tools themselves, of course).

Table of contents
  1. "Fink Interview, Part I"
  2. "Fink Interview, Part II"
e p (0)    20 Comment(s)

Technology White Papers

See More