[Scribus] MacOS native version

[Andreas Vox]

Craig Ringer wrote:

> 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.

Since this post appears to contain more questions than others I'll 
respond to this :-)

> Like Craig Bradney, I'd be very interested in knowing how you handled
> fonts and how you worked around the gdk dependencies.

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.

> >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?

That was my quick&dirty approach again. It was easier for me to use 
fink.

>
> > 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?

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.

> >          /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...

Yes. Couldn't find one in OSX.


> >          /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.

Yes, unless you replace it by Cairo before ;-)
>
> >          /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.

> >          /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?

Yes, libc, libm and others.

>
> >          /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 guess Apple needs Objective C routines for image handling most of the
time, so they have equivalents in their Cocoa framework.

> >          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 :-(
>
> >          /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?
>
> Me!

Great.

> 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?

> 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.

> (It's funny - I don't actually like macs.

Ha! I wont talk to you any more. ;-)

> But I still want to help port
> Scribus across.)

You should know that MacOSX is the most popular Unix on earth :-)

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