|
|
(32 intermediate revisions by 11 users not shown) |
Line 1: |
Line 1: |
− | {{Discussion Index}}
| + | [[Category:MacOS]] |
| + | =Native version of Scribus for Mac OSX= |
| + | ==Stable== |
| + | * You can grab the latest stable version of Scribus from [[Download|here]] or you can get full installation instructions (including installation of GhostScript) [[OS X - Installing Scribus on your Mac the easy way|here]]. |
| | | |
− | On the Scribus mailing list, Andreas Vox have started an interesting discussion on bringing Scribus natively to Mac OSX. Join in with your opinion!
| + | ==Development== |
| + | * Add Macports link |
| + | * Add Fink link |
| + | * [[Scribus and Homebrew]] (compile through package manager) |
| | | |
| + | = Obsolete = |
| + | * Native Aqua version |
| + | ** [[http://docs.scribus.net/index.php?lang=en&page=install5 Official Docs How to building the native Aqua version of Scribus 1.3.5 from SVN using MacPorts and Qt4 ]] - Instruction on building the native Aqua version of Scribus from SVN |
| + | * X11 version |
| + | ** [[Installing Scribus on Mac with MacPorts]] - How to install and run Scribus 1.3.3.9 ''(27/05/2007)'' |
| + | ** [[Installing Scribus from CVS sources on Mac OS X]] - Howto on installing Scribus from CVS sources through Fink |
| + | ** [[Installing Scribus on Mac OS X]] - Howto on installing the stable version of Scribus through Fink |
| + | ** [[Installing Scribus on Mac Intel]] - from the Scribus Archives |
| | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009442.html
| + | ==Obsolete PPC OSX== |
− | | + | * <del>Scribus 1.3.x on MacOSX is still work in progress, but there are very usable, frequently updated binary test builds. Details are here http://www.scribus.net/?q=macosx</del> |
− | I noticed that you still require X11 for the MacOSX version of Scribus.
| + | * <del>Builds of the '''native Aqua version''' are now available from [http://sourceforge.net/project/showfiles.php?group_id=125235&package_id=201484 sourceforge] (choose the 1.3.5svn version)</del> |
− | | + | * <del>[http://aqua.scribus.net aqua.scribus.net] is the place go for the '''native Aqua version''', when you want to know more details and download the latest packages (but this link now seems to redirect to a general page)</del> |
− | I managed to compile Scribus 1.2.1 with Qt/Mac native and I wondered
| + | * <del>[http://bugs.scribus.net/view.php?id=2015 List of all known issues] — check this list before reporting new errors |
− | if you'd like to get some hints how it is done. In fact it was quite
| |
− | easy
| |
− | once I solved my libtool problems (screenshot attached :-) )
| |
− | | |
− | So this is what I did:
| |
− | | |
− | 0. Started with the Scribus 1.2.1 sources
| |
− | | |
− | 1. configured Scribus to use Qt/Mac inbstead of the fink Qt version
| |
− | | |
− | 2. replaced all gdk-* sourcefiles with empty files
| |
− | | |
− | 3. commented out all #include <X11.h> etc.
| |
− | | |
− | 4. Removed GC from scpainter
| |
− | | |
− | 5. Rewrote scpainter::end():
| |
− | | |
− | void ScPainter::end()
| |
− | {
| |
− | QImage qimg(m_width, m_height, 32, QImage::BigEndian);
| |
− | QRgb * bits = (QRgb *) qimg.bits();
| |
− | int words = qimg.numBytes() / 4;
| |
− | art_u8 * p = m_buffer;;
| |
− | for (int i=0; i < words; ++i) {
| |
− | art_u8 r = *p++;
| |
− | art_u8 g = *p++;
| |
− | art_u8 b = *p++;
| |
− | art_u8 a = *p++;
| |
− | *bits++ = qRgba(r,g,b,a);
| |
− | }
| |
− | bitBlt(m_target, 0, 0, &qimg);
| |
− | }
| |
− | | |
− | | |
− | 6. libtool nuisances:
| |
− | | |
− | 6a) Apply fink patch to use correct -bundle for libtool
| |
− | | |
− | 6b) Remove -s option (stripping is no good idea if you want to link
| |
− | plugins)
| |
− | | |
− | 7. Make Scribus ignore any "-psn_*" commandline options passed by Qt
| |
− | | |
− | 8. Adjust a few #includes to MacOSX
| |
− | | |
− | 9. Created a rudimentary Scribus.app/ bundle (thanks to Ronald Florence
| |
− | who did the same for LyX so I just had to replace a few strings)
| |
− | | |
− | The application still uses the files (plugins etc.) which Scribus
| |
− | installs to /usr/local.
| |
− | The following libraries get linked:
| |
− | | |
− | /Applications/local/Scribus.app/Contents/MacOS/scribus:
| |
− | /sw/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)
| |
− | /sw/lib/libart_lgpl_2.2.dylib (compatibility version 6.0.0, current version 6.16.0)
| |
− | /usr/local/lib/libfreetype6.dylib (compatibility version 6.2.0, current version 6.3.4)
| |
− | /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2.5.0)
| |
− | /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
| |
− | /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
| |
− | /sw/lib/liblcms.1.dylib (compatibility version 2.0.0, current version 2.12.0)
| |
− | /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)
| |
− | /sw/lib/libtiff.3.dylib (compatibility version 3.6.0, current version 3.6.1)
| |
− | libqt-mt.3.dylib (compatibility version 3.3.0, current version 3.3.3)
| |
− | /sw/lib/libpng.3.dylib (compatibility version 3.0.0, current version 3.0.0)
| |
− | /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.0.0)
| |
− | | |
− | I still have problems with some plugins and some icons don't show, but
| |
− | otherwise it's usable.
| |
− | Anyone who want's to test and help finishing it to a proper MacOSX
| |
− | application?
| |
− | | |
− | Regards
| |
− | Andreas
| |
− | | |
− | Ah, yes, the screenshot:
| |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20050305/a9711066/scribus-screen-shot-small-0001.jpg
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009443.html | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009444.html
| |
− | | |
− | | |
− | Looks great.. erm.. what replaces the gdk sources then?
| |
− | | |
− | and what replaces the X call(s) in scfonts.cpp ? Does this mean you always
| |
− | have to add in the font paths via the additional font paths setup?
| |
− | | |
− | Craig
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009447.html
| |
− | | |
− | This does seem extremely interesting. I've been meaning to try an Aqua-
| |
− | native port of 1.3cvs for a while, but I just don't have the mac
| |
− | development experience, and there was the gdk-pixbuf issue to consider.
| |
− | | |
− | Like Craig Bradney, I'd be very interested in knowing how you handled
| |
− | fonts and how you worked around the gdk dependencies.
| |
− | | |
− | From what I see in your library list below, I see that you still link to
| |
− | quite a few fink-supplied libraries. I imagine we'd have to ship
| |
− | prebuilt copies of those, or statically link them, with any
| |
− | "installable" Aqua Scribus build. Sound about right?
| |
− | | |
− | | |
− | '' 9. Created a rudimentary Scribus.app/ bundle (thanks to Ronald Florence
| |
− | who did the same for LyX so I just had to replace a few strings)''
| |
− | | |
− | | |
− | That's very, very useful to know.
| |
− | | |
− | Did you end up using Xcode for all this, or just tweaked the existing
| |
− | build to use Qt/Aqua?
| |
− | | |
− | | |
− | ''/sw/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)''
| |
− | | |
− | | |
− | Does MacOS X not provide libjpeg? That's from fink by the looks...
| |
− | | |
− | | |
− | ''/sw/lib/libart_lgpl_2.2.dylib (compatibility version 6.0.0, current version 6.16.0)''
| |
− | | |
− | | |
− | I imagine we'd have to bundle or statically link libart.
| |
− | | |
− | | |
− | ''/usr/local/lib/libfreetype6.dylib (compatibility version 6.2.0, current version 6.3.4)''
| |
− | | |
− | ''/usr/local/lib . Interesting. Did you compile a Mac-native version of freetype yourself, or use an installer package or something?''
| |
− | | |
− | ''/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2.5.0)''
| |
− | | |
− | | |
− | Glad to see we can rely on MacOS/X for CUPS libraries.
| |
− | | |
− | | |
− | ''/usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)''
| |
− | | |
− | ''/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)''
| |
− | | |
− | ''/sw/lib/liblcms.1.dylib (compatibility version 2.0.0, current version 2.12.0)''
| |
− | | |
− | | |
− | Fink again. I guess that'd be another static linking candidate.
| |
− | | |
− | | |
− | ''/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)''
| |
− | | |
− | | |
− | Is this MacOS/X's libc equivalent? Or does it provide the core Aqua
| |
− | routines etc?
| |
− | | |
− | | |
− | ''/sw/lib/libtiff.3.dylib (compatibility version 3.6.0, current version 3.6.1)''
| |
− | | |
− | | |
− | Hmm, you got libtiff from fink too. Again, I'm rather surprised OS/X
| |
− | doesn't include that.
| |
− | | |
− | | |
− | ''libqt-mt.3.dylib (compatibility version 3.3.0, current version 3.3.3)''
| |
− | | |
− | ''/sw/lib/libpng.3.dylib (compatibility version 3.0.0, current version 3.0.0)''
| |
− | | |
− | | |
− | libpng from fink too :-(
| |
− | | |
− | | |
− | ''Anyone who want's to test and help finishing it to a proper MacOSX application?''
| |
− | | |
− | | |
− | Me!
| |
− | | |
− | Especially if you can give some more detailed info, especially about how
| |
− | you did the build and where the various libraries are from.
| |
− | | |
− | One thing I'm curious about... I know MacOS/X has five different major
| |
− | APIs:
| |
− | | |
− | Carbon (Cleaned up OS/9)
| |
− | Classic (Virtual OS/9 for unchanged apps)
| |
− | Cocoa (Native MacOS/X Objective C/Aqua)
| |
− | Java (duh!)
| |
− | POSIX/BSD/X11 (unix-style apps, usually console or X11 based)
| |
− | | |
− | but I was always under the impression they were rather separate, and one
| |
− | couldn't for example write a POSIX/BSD app that used Cocoa (Aqua)
| |
− | graphics. I also thought Cocoa apps had to link to 'Libraries' and
| |
− | 'Frameworks' that were different from the POSIX/BSD style shared
| |
− | libraries.
| |
− | | |
− | Do you know if this distinction is less strict than I thought, and one
| |
− | can mix and match to an extent? Or is Qt doing some magic to protect us
| |
− | from these issues? Can we do things like use the MacOS/X font APIs? Have
| |
− | you built Scribus as a Cocoa application, a POSIX/BSD app, or some
| |
− | hybrid of the two?
| |
− | | |
− | If you know where I can go to find out more about MacOS/X development
| |
− | and porting from UNIX, that'd be really handy too...
| |
− | | |
− | (It's funny - I don't actually like macs. But I still want to help port
| |
− | Scribus across.)
| |
− | | |
− | --
| |
− | Craig Ringer
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009448.html | |
− | | |
− | On Sat, 2005-03-05 at 09:41 +0100, Craig Bradney wrote:
| |
− | | |
− | ''and what replaces the X call(s) in scfonts.cpp ? Does this mean you always have to add in the font paths via the additional font paths setup?''
| |
− | | |
− | I expect fontconfig, as used in 1.3, should work fine for this job. It
| |
− | probably won't permit the use of MacOS9 style resource-fork-based fonts
| |
− | (PostScript / Type 1 and TrueType) or OS/X native style .dfont fonts,
| |
− | though.
| |
− | | |
− | I'm rather more curious about what replaced gdk-* and the more general
| |
− | issues with how it all works, though.
| |
− | | |
− | --
| |
− | Craig Ringer
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009452.html
| |
− | | |
− | Please sign me up for the porting/testing effort for the native Aqua
| |
− | Scribus. I spent months last year trying to get it to build. Alas, I
| |
− | don't know C++ at all, and always had to stop when I ran into the
| |
− | screenpaint/X11 calls: just didn't know how to work around them.
| |
− | | |
− | I've gotten pretty knowledgable about building and deploying app bundles
| |
− | from Qt, however: I'm comfortable with Qt/Mac from a build standpoint,
| |
− | so I think I can help there.
| |
− | | |
− | It may not be possible to have the ideal binary distribution, which is a
| |
− | ~ standalone, drag-and-drop app bundle. One can do that if you compile Qt
| |
− | to be statically linked, rather than dynamically linked. However, I know
| |
− | Scribus has other external dependencies as well. Still, if Scribus can
| |
− | be built against a static Qt, then it should be simple to isolate the
| |
− | other external dependencies (libtif? etc.) into a Mac pkg installer. A
| |
− | standard Mac user in Scribus' target market (publishing, graphics) isn't
| |
− | going to want to install all of Qt just to run Scribus, even if you
| |
− | provide a binary installer (I maintain PyQt for the Mac with a binary
| |
− | installer, so I have some insight here).
| |
− | | |
− | The example of Gimp.app (a Mac app bundle of Gimp 2.2.x) is instructive
| |
− | here: it's become wildly popular in terms of downloads because it wraps
| |
− | all the Gimp binaries and GTK libraries into a single app bundle. Its
| |
− | only external dependency is Apple's X11 environment.
| |
− | | |
− | One area where we'd have to tread carefully is if the Scribus build
| |
− | links to Fink libraries. That complicates matters, for several reasons.
| |
− | One, the goal should be to make Scribus as standalone/isolated as
| |
− | possible; I don't think that requiring a separate installation of Fink
| |
− | should be part of this. Also, the Fink leaders are serious about
| |
− | enforcing GPL on their packages: I was warned last year when I asked
| |
− | about making an X11 app bundle of Scribus that I'd have to carefully
| |
− | document all my steps, make all my source code available, etc. I decided
| |
− | all that was too complex for me to undertake by myself. If Fink winds up
| |
− | being part of this equation, then I just want to highlight the due
| |
− | diligence that would need to be taken. Perhaps Martin can provide
| |
− | advice on this front.
| |
− | | |
− | Another question: where should this project be hosted? My little
| |
− | AquaScribus app launcher is available from the Scribus site, as well as
| |
− | from my own server, but it's a very small download. Depending on the
| |
− | libraries, a Mac pkg installer of Scribus could be 20-50 megabytes to
| |
− | download. Can the Scribus servers in the UK handle this, or should a
| |
− | Sourceforge project be set up for the back end?
| |
− | | |
− | I'm incredibly excited about this: I've been wanting to ditch my
| |
− | Microsoft/Adobe toolchain in my publishing business (I publish about 50
| |
− | poetry books per year via POD) for some time, but Scribus hasn't been
| |
− | quite mature enough for my needs. (I have used it successfully with
| |
− | cover design only, so I know that Scribus can handle commercial work,
| |
− | but those covers were more work than a comparable version in InDesign
| |
− | would be.) With 1.2.1 supporting styled text import, it looks like
| |
− | Scribus may have crossed that threshold. And with NeoOffice J running
| |
− | natively on the Mac, that and Scribus.app would allow me to ditch X11
| |
− | for everything except Gimp.
| |
− | | |
− | So, just let me know what I need to do! I can't wait!
| |
− | | |
− | - --
| |
− | Cheers,
| |
− | | |
− | Kevin Walzer, PhD
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009460.html
| |
− | | |
− | Kevin Walzer wrote:
| |
− | | |
− | <i>
| |
− | The example of Gimp.app (a Mac app bundle of Gimp 2.2.x) is instructive here: it's become wildly popular in terms of downloads because it wraps all the Gimp binaries and GTK libraries into a single app bundle. Its only external dependency is Apple's X11 environment.
| |
− | </i> | |
− | | |
− | Gimp.app uses a whole bunch of dynamic libraries from Fink. It just puts
| |
− | them into the bundle and ships them with the app. Scribus.app could do
| |
− | the same, at least for the smaller libs. I agree that libqt is perhaps
| |
− | better linked statically if possible.
| |
− | | |
− | <i> | |
− | One area where we'd have to tread carefully is if the Scribus build links to Fink libraries.
| |
− | That complicates matters, for several reasons.
| |
− | One, the goal should be to make Scribus as standalone/isolated as possible;
| |
− | I don't think that requiring a separate installation of Fink should be part of this.
| |
− | Also, the Fink leaders are serious about enforcing GPL on their packages:
| |
− | I was warned last year when I asked about making an X11 app bundle of Scribus that I'd have to carefully document all my steps,
| |
− | make all my source code available, etc. I decided all that was too complex for me to undertake by myself.
| |
− | If Fink winds up being part of this equation, then I just want to highlight the due diligence that would need to be taken.
| |
− | Perhaps Martin can provide advice on this front.
| |
− | </i>
| |
− | | |
− | Actually I even annoyed the guy who distributes Gimp.app until he
| |
− | provided a detailed account of his build procedure. He has such a text
| |
− | now on his web site at
| |
− | http://gimp-app.sourceforge.net/gimp.app.howto.txt, and I think this is | |
− | a good thing. It can be useful for example for a project like
| |
− | Scribus.app. That's is the idea of this part of the GPL, namely to allow
| |
− | others to learn from your work.
| |
− | | |
− | I don't see any conflict between Fink and a possible standalone
| |
− | Scribus.app. I could even imagine a Fink package that produces this
| |
− | standalone Scribus.app which could then be distributed from the scribus
| |
− | servers. Just because such a thing has not yet been done, doesn't mean
| |
− | it is impossible.
| |
− | | |
− | There is another example of a Mac app bundle made with the help of Fink:
| |
− | Nicotine.app http://nicotine-app.sourceforge.net/cgi-bin/wiki.pl. The
| |
− | maintainer of this project (vasi) is also one of the main Fink
| |
− | developers. On that page there are even two more app bundles made in the
| |
− | same way. All these app bundles are running with X11, though.
| |
− | | |
− | | |
− | ''So, just let me know what I need to do! I can't wait!'' | |
− | | |
− | | |
− | The first and foremost point is to get this thing working.
| |
− | | |
− | All other questions about packaging etc are secondary. You remember that
| |
− | Ben Reed had a scribus version using Qt/Mac already some 2 years ago,
| |
− | but it never worked correctly. Maybe both Qt/Mac and scribus are now in
| |
− | a shape that makes this possible, but this has to be seen.
| |
− | | |
− | --
| |
− | Martin
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009478.html
| |
− | | |
− | Craig Ringer wrote:
| |
− | | |
− | <i>
| |
− | This does seem extremely interesting. I've been meaning to try an Aqua-
| |
− | native port of 1.3cvs for a while, but I just don't have the mac
| |
− | development experience, and there was the gdk-pixbuf issue to consider.
| |
− | </i>
| |
− | | |
− | | |
− | Since this post appears to contain more questions than others I'll
| |
− | respond to this :-)
| |
− | | |
− | <i>
| |
− | Like Craig Bradney, I'd be very interested in knowing how you handled fonts and how you worked around the gdk dependencies.
| |
− | </i>
| |
− | | |
− | Ok, short one first: Fonts. I just commented out the body of
| |
− | addXFontpath.
| |
− | Currently I only have Courier/Luxi/Utopia etc from /usr/X11R6/bin.
| |
− | Some work needs to be done here.
| |
− | | |
− | About the gdk-pixmap business: my first step was to delete/comment out
| |
− | anything
| |
− | which uses X11. I have a native LyX version based on Qt/Mac, so I know
| |
− | this is
| |
− | possible. Unfortunately when I started Scribus the main drawing area
| |
− | was black.
| |
− | | |
− | Then I looked at the code and saw that in ScPainter::end() the libart
| |
− | buffer is just
| |
− | copied to an X pixmap. I then tried QImage for this:
| |
− |
| |
− |
| |
− | QImage qimg(m_buffer, m_width, m_height, 0, 0);
| |
− | bitBlt(target, 0, 0, &qimg);
| |
− | | |
− | | |
− | That worked but after a while I noticed the colors where wrong. Some
| |
− | testing and
| |
− | thinking revealed that libart uses RGBA, while Qt uses ARGB. That's how
| |
− | I arrived
| |
− | at the current code: just copy the libart buffer into a QImage
| |
− | manually.
| |
− | | |
− | The gdk-sources are not needed at all, QImage/bitBlt do all the work.
| |
− | This should also
| |
− | work for other platforms btw.
| |
− | I'm not sure if scrolling is as fast as in X11, but it feels ok.
| |
− | Sometimes I see artefacts
| |
− | of half-drawn screens while scrolling, but once I stop everything looks
| |
− | ok.
| |
− | | |
− | | |
− | <i>
| |
− | From what I see in your library list below, I see that you still link
| |
− | to quite a few fink-supplied libraries. I imagine we'd have to ship
| |
− | prebuilt copies of those, or statically link them, with any "installable" Aqua Scribus build. Sound about right?
| |
− | </i>
| |
− | | |
− | | |
− | That was my quick&dirty approach again. It was easier for me to use
| |
− | fink.
| |
− | | |
− | | |
− | <i>
| |
− | Did you end up using Xcode for all this, or just tweaked the existing build to use Qt/Aqua?
| |
− | </i>
| |
− | | |
− | | |
− | No XCode, not even Eclipse. Just Developertools gcc 3.3.3, Terminal.app
| |
− | and vi :-)
| |
− | The app-bundle is just a bunch of files where you have to copy your
| |
− | executable to the right position and provide some information in an XML-
| |
− | based Info.plist file.
| |
− | I haven't produced icons yet, I will use the XCode tool for that.
| |
− | | |
− | | |
− | | |
− | <i>Does MacOS X not provide libjpeg? That's from fink by the looks...</i>
| |
− | | |
− | | |
− | Yes. Couldn't find one in OSX.
| |
− | | |
− | | |
− | <i>I imagine we'd have to bundle or statically link libart.</i>
| |
− | | |
− | Yes, unless you replace it by Cairo before ;-)
| |
− | | |
− | | |
− | <i>Did you compile a Mac-native version of freetype yourself, or use an installer package or something?</i>
| |
− | | |
− | | |
− | I installed the fink one but obviously configure found the one from X11.
| |
− | | |
− | | |
− | <i>
| |
− | > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)
| |
− | | |
− | Is this MacOS/X's libc equivalent? Or does it provide the core Aquaroutines etc?
| |
− | </i>
| |
− | | |
− | | |
− | Yes, libc, libm and others.
| |
− | | |
− | <i>
| |
− | > /sw/lib/libtiff.3.dylib (compatibility version 3.6.0, current version 3.6.1)
| |
− | | |
− | | |
− | Hmm, you got libtiff from fink too. Again, I'm rather surprised OS/X doesn't include that.
| |
− | </i>
| |
− | | |
− | | |
− | I guess Apple needs Objective C routines for image handling most of the
| |
− | time, so they have equivalents in their Cocoa framework.
| |
− | | |
− | | |
− | <i>Especially if you can give some more detailed info, especially about how you did the build and where the various libraries are from.</i>
| |
− | | |
− | | |
− | Maybe we can stick to the fink ones for the time beeing and get the
| |
− | other
| |
− | stuff right, first?
| |
− | | |
− | >One thing I'm curious about... I know MacOS/X has five different major APIs:
| |
− | | |
− | > Carbon (Cleaned up OS/9)
| |
− | | |
− | > Classic (Virtual OS/9 for unchanged apps) Emulator.
| |
− | | |
− | > Cocoa (Native MacOS/X Objective C/Aqua)
| |
− | | |
− | Objective C framework from Nextstep
| |
− | | |
− | > Java (duh!)
| |
− | | |
− | Has Cocoa bindings.
| |
− | | |
− | > POSIX/BSD/X11 (unix-style apps, usually console or X11 based)
| |
− | | |
− | Can be mixed with Carbon. I think X11 and Qt/Mac are also based on Carbon.
| |
− | | |
− | It's all layered. I guess all graphics eventually end up in the Quartz
| |
− | library.
| |
− | For a single application it is very advisable to stick to one
| |
− | framework, though.
| |
− | | |
− | | |
− | > but I was always under the impression they were rather separate, and
| |
− | > one
| |
− | > couldn't for example write a POSIX/BSD app that used Cocoa (Aqua)
| |
− | > graphics. I also thought Cocoa apps had to link to 'Libraries' and
| |
− | > 'Frameworks' that were different from the POSIX/BSD style shared
| |
− | > libraries.
| |
− | >
| |
− | > Do you know if this distinction is less strict than I thought, and one
| |
− | > can mix and match to an extent? Or is Qt doing some magic to protect us
| |
− | > from these issues? Can we do things like use the MacOS/X font APIs?
| |
− | > Have
| |
− | > you built Scribus as a Cocoa application, a POSIX/BSD app, or some
| |
− | > hybrid of the two?
| |
− | | |
− | Qt/Mac app :-)
| |
− | You can link to any framework you want, so now Scribus links to
| |
− | Posix/BSD
| |
− | for non-graphics stuff and Qt/Mac and libart for graphics.
| |
− | Cocoa is more difficult because that's Objective C.
| |
− | | |
− | Scribus already almost exclusively uses Qt for graphics. The
| |
− | buffer-copy in
| |
− | scpainter and the fontpaths are the only X11 dependencies as far as I
| |
− | know.
| |
− | | |
− | | |
− | > If you know where I can go to find out more about MacOS/X development
| |
− | > and porting from UNIX, that'd be really handy too...
| |
− | | |
− | There are developer docs but mainly you can just use gcc/gdb/make etc.
| |
− | You just have to read the Apple specific manpages for these tools, eg.
| |
− | the special linking options of gcc for Darwin, -framework instead of -I,
| |
− | or the fact that you can call gdb on a Mac.app application directly.
| |
− | | |
− | OK, the next steps would be:
| |
− | | |
− | * decide if we want to work with 1.2.1 or 1.3cvs
| |
− | * fix the makefile for MacOSX (include the fink changes)
| |
− | * the fontpath issue
| |
− | * use dynamic paths to access Scribus.app/Contents/Resources instead of /usr/local/lib/scribus (We can build on some LyX work for that)
| |
− | * Provide a howto to compile Scribus for MacOS native (req. libraries, configure options, installation, ...)
| |
− | * Test Scribus/Mac for regression wrt. Scribus/X11
| |
− | * When this works try to get a self contained binary with bundled/static libs.
| |
− | | |
− | Ciao
| |
− | | |
− | /Andreas
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009466.html
| |
− |
| |
− |
| |
− | On Sat, 2005-03-05 at 20:49 +0100, Craig Bradney wrote:
| |
− | | |
− | > Sure its possible. In the worst case we can just supply all the libraries
| |
− | > ourselves. Not very disk space friendly but once the X dependency is really
| |
− | > gone it might not be that much really. | |
− | | |
− | I think it'd be best to bundle or statically link all libs not included
| |
− | in MacOS/X as shipped, if at all possible. Mac users seem happy to
| |
− | accept somewhat bloated apps in exchange for standalone installs, and
| |
− | this is probably something that should be taken into account.
| |
− | | |
− | It's probably not a big deal whether they're bundled as separate libs or
| |
− | statically linked thanks to the Mac `.app' dir setup that lets you
| |
− | collect up all files for an app into an "object" that behaves to the
| |
− | user as it if was a single program binary.
| |
− | | |
− | --
| |
− | Craig Ringer
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009480.html
| |
− | | |
− | | |
− | > OK, the next steps would be:
| |
− | >
| |
− | > * decide if we want to work with 1.2.1 or 1.3cvs
| |
− | | |
− | I'd suggest 1.3 as we arent adding any new features to 1.2.1. 1.2.x works
| |
− | already on Mac. Ok its not so simple or pretty
| |
− | | |
− | > * fix the makefile for MacOSX (include the fink changes)
| |
− | > * the fontpath issue
| |
− | | |
− | 1.3 supports fontconfig.. I'm assuming fontconfig is ok via Fink. We will
| |
− | strip the X dependency from 1.3 and rely on fontconfig soon enough.
| |
− | | |
− | We have a cairo build now, have had for ages, but its not fast enough to
| |
− | switch yet. Your QImage idea might work on X11 just as quickly as libart
| |
− | though..
| |
− | | |
− | Craig
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009482.html
| |
− | | |
− | | |
− | Two small remarks:
| |
− | | |
− | Andreas Vox wrote:
| |
− | []
| |
− | >> > /usr/local/lib/libfreetype6.dylib (compatibility version
| |
− | >> 6.2.0,
| |
− | >> > current version 6.3.4)
| |
− | >>
| |
− | >> /usr/local/lib . Interesting. Did you compile a Mac-native version of
| |
− | >> freetype yourself, or use an installer package or something?
| |
− | >
| |
− | >
| |
− | > I installed the fink one but obviously configure found the one from X11.
| |
− | | |
− | Actually, it found yet another one. The freetype from current Apple X11
| |
− | is version 2.1.0 which is too old to work for scribus. Fink has versions
| |
− | 2.1.4 and 2.1.9, but they show other compatibility versions than what
| |
− | you are showing.
| |
− | | |
− | >> > /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current
| |
− | >> > version 2.5.0)
| |
− | >>
| |
− | >> Glad to see we can rely on MacOS/X for CUPS libraries.
| |
− | | |
− | But headers like <cups/cups.h> are not supplied by Apple. You need a
| |
− | small package cups-dev from Fink (or wait 4 months for MacOSX 10.4).
| |
− | [] | |
− | > * decide if we want to work with 1.2.1 or 1.3cvs
| |
− | | |
− | It is probably natural for scribus developers to eye 1.3x here, and I
| |
− | would agree if this means that 1.3x will be cleaned up for the Mac.
| |
− | Right now, I haven't yet got it working correctly.
| |
− | | |
− | - There is a bug in the prefs plugin that prevents the preferences
| |
− | dialog from coming up, but it is not the same bug as the one in 1.2.1,
| |
− | and I haven't yet identified it. There is another bug in the svgex
| |
− | plugin, but this is less important than the preferences.
| |
− | | |
− | - The colors are all wrong, again. I don't know which version of David
| |
− | Purton's patch went into the cvs sources, but the result looks like with
| |
− | the first version of his patch which was not correct for bigendian machines.
| |
− | | |
− | --
| |
− | Martin
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009483.html | |
− | | |
− | | |
− | Martin wrote:
| |
− | | |
− | | |
− | > Two small remarks:
| |
− | >
| |
− | > Andreas Vox wrote:
| |
− | > []
| |
− | > >> > /usr/local/lib/libfreetype6.dylib (compatibility version
| |
− | > >> 6.2.0,
| |
− | > >> > current version 6.3.4)
| |
− | > >>
| |
− | > >> /usr/local/lib . Interesting. Did you compile a Mac-native version
| |
− | > of
| |
− | > >> freetype yourself, or use an installer package or something?
| |
− | > >
| |
− | > >
| |
− | > > I installed the fink one but obviously configure found the one from
| |
− | > X11.
| |
− | >
| |
− | > Actually, it found yet another one.
| |
− | | |
− | | |
− | You are right. Courtesy of word2x / libwmf.
| |
− | | |
− | ...
| |
− | > It is probably natural for scribus developers to eye 1.3x here,
| |
− | | |
− | | |
− | Fine. I'll start with patching now :-)
| |
− | | |
− | | |
− | > and I
| |
− | > would agree if this means that 1.3x will be cleaned up for the Mac.
| |
− | > Right now, I haven't yet got it working correctly.
| |
− | >
| |
− | > - There is a bug in the prefs plugin that prevents the preferences
| |
− | > dialog from coming up, but it is not the same bug as the one in 1.2.1,
| |
− | > and I haven't yet identified it. There is another bug in the svgex
| |
− | > plugin, but this is less important than the preferences.
| |
− | >
| |
− | > - The colors are all wrong, again. I don't know which version of David
| |
− | > Purton's patch went into the cvs sources, but the result looks like
| |
− | > with
| |
− | > the first version of his patch which was not correct for bigendian
| |
− | > machines.
| |
− | | |
− | | |
− | This is Scribus/X11, yes? Is David Purton's patch changing the
| |
− | gdk-sources
| |
− | or libart or something else?
| |
− | | |
− | | |
− | Ciao
| |
− | /Andreas
| |
− | | |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009484.html
| |
− | | |
− | | |
− | On Sat, 2005-03-05 at 19:18 +0100, Andreas Vox wrote:
| |
− | | |
− | > Ok, short one first: Fonts. I just commented out the body of
| |
− | > addXFontpath. Currently I only have Courier/Luxi/Utopia etc
| |
− | > from /usr/X11R6/bin. Some work needs to be done here.
| |
− | | |
− | Fontconfig should take care of that for now. In the medium term I'd like
| |
− | to look at trying to access fonts via the MacOS/X font apis ... but that
| |
− | might require things like a carbonized version of freetype that knows
| |
− | about resource forks.
| |
− | | |
− | > No XCode, not even Eclipse. Just Developertools gcc 3.3.3,
| |
− | > Terminal.app and vi :-) The app-bundle is just a bunch of files where
| |
− | > you have to copy your executable to the right position and provide
| |
− | > some information in an XML-based Info.plist file. I haven't produced
| |
− | > icons yet, I will use the XCode tool for that.
| |
− | | |
− | That's very useful to know.
| |
− | | |
− | > > Especially if you can give some more detailed info, especially about
| |
− | > > how
| |
− | > > you did the build and where the various libraries are from.
| |
− | >
| |
− | > Maybe we can stick to the fink ones for the time beeing and get the
| |
− | > other stuff right, first?
| |
− | | |
− | That sounds sensible.
| |
− | | |
− | > > POSIX/BSD/X11 (unix-style apps, usually console or X11 based)
| |
− | > Can be mixed with Carbon. I think X11 and Qt/Mac are also based on
| |
− | > Carbon.
| |
− | | |
− | Thankyou. I wasn't aware POSIX/BSD apps could use Carbon ... that's
| |
− | extremely handy to know. It also eliminates one of my biggest concerns
| |
− | with a Mac native port - the ability to use Mac-native APIs for font
| |
− | access, accessing color profiles, etc without having to do some sort of
| |
− | Objective-C wrapper layer.
| |
− | | |
− | > > If you know where I can go to find out more about MacOS/X development
| |
− | > > and porting from UNIX, that'd be really handy too...
| |
− | >
| |
− | > There are developer docs but mainly you can just use gcc/gdb/make etc.
| |
− | > You just have to read the Apple specific manpages for these tools, eg.
| |
− | > the special linking options of gcc for Darwin, -framework instead of -I,
| |
− | > or the fact that you can call gdb on a Mac.app application directly.
| |
− | | |
− | Good to know. I was more hoping for a "survial guide for UNIX
| |
− | developers" though, ie what's different, how to handle issues like
| |
− | resource forks, .app bundles, the number of different APIs, etc. I'll
| |
− | have to check out the main dev docs - I had a quick look before but
| |
− | didn't spot any sort of summary for folks coming from a *nix background.
| |
− | | |
− | > You should know that MacOSX is the most popular Unix on earth :-)
| |
− | | |
− | I just wish they'd integrate X11 more, so it wasn't the most popular
| |
− | UNIX-like OS on earth and the only workstation one that encourages users
| |
− | to avoid X11 ;-)
| |
− | | |
− | I like my network transparency.
| |
− | | |
− | > * decide if we want to work with 1.2.1 or 1.3cvs
| |
− | | |
− | I tend to agree with MrB re using 1.3cvs. While it'd mean a longer lead
| |
− | time to get a stable, usable build, and more changes happening along the
| |
− | way, it should mean less duplicated work and merging.
| |
− | | |
− | I guess I'll have to finish getting XCode and the dev tools set up on
| |
− | the eMac at work.
| |
− | | |
− | --
| |
− | Craig Ringer
| |
− | | |
− | | |
− | http://nashi.altmuehlnet.de/pipermail/scribus/2005-March/009485.html
| |
− | | |
− |
| |
− | Craig Ringer wrote:
| |
− | > In the medium term I'd like
| |
− | > to look at trying to access fonts via the MacOS/X font apis ... but
| |
− | > that
| |
− | > might require things like a carbonized version of freetype that knows
| |
− | > about resource forks.
| |
− | | |
− | | |
− | AFAIK resource forks are deprecated in MacOSX.
| |
− | | |
− | | |
− | > Thankyou. I wasn't aware POSIX/BSD apps could use Carbon ... that's
| |
− | > extremely handy to know. It also eliminates one of my biggest concerns
| |
− | > with a Mac native port - the ability to use Mac-native APIs for font
| |
− | > access, accessing color profiles, etc without having to do some sort of
| |
− | > Objective-C wrapper layer.
| |
− | | |
− | | |
− | That's why they created Carbon in the first place :-) -- noone wanted
| |
− | to switch
| |
− | to Objective C.
| |
− | | |
− | | |
− | > > > If you know where I can go to find out more about MacOS/X
| |
− | > development
| |
− | > > > and porting from UNIX, that'd be really handy too...
| |
− | > >
| |
− | > > There are developer docs but mainly you can just use gcc/gdb/make
| |
− | > etc.
| |
− | > > You just have to read the Apple specific manpages for these tools,
| |
− | > eg.
| |
− | > > the special linking options of gcc for Darwin, -framework instead of
| |
− | > -I,
| |
− | > > or the fact that you can call gdb on a Mac.app application directly.
| |
− | >
| |
− | > Good to know. I was more hoping for a "survial guide for UNIX
| |
− | > developers" though, ie what's different, how to handle issues like
| |
− | > resource forks, .app bundles, the number of different APIs, etc. I'll
| |
− | > have to check out the main dev docs - I had a quick look before but
| |
− | > didn't spot any sort of summary for folks coming from a *nix
| |
− | > background.
| |
− | | |
− | Look for Unix porting guide. Manpages for gcc, glibtool, otool, etc.
| |
− | | |
− | I also found
| |
− | | |
− | http://sveinbjorn.vefsyn.is/writings
| |
− | and
| |
− | | |
− | http://kernelthread.com/mac/osx/tools.html
| |
− | | |
− | useful.
| |
− | | |
− | Ciao
| |
− | /Andreas
| |