Subject: Re: FAQ -- what do I port?
From: Thomas Fletcher (thomasf@qnx.com)
Date: Fri Feb 25 2000 - 15:27:14 CST
On Fri, 25 Feb 2000, Paul Rohr wrote:
> It would be convenient if we had a suggested order for which cells to tackle
> in what order, but it's been so long since I was involved in a new port that
> link failures are probably your best guide.
>
> Since Thomas has been ripping through the QNX port recently, he'd probably
> have some excellent suggestions about a practical implementation order.
Well not having looked at Bob's matrix this may not be
the most optimal way to approach things ... but since I've
done both the BeOS and the QNX/Photon ports I've got a few
ideas about where to get started.
#1 of course is to go through the tree and rip out the
platform which most closely matches your platform. When
in doubt I would suggest the Unix platform since most of
the Unix graphics calls are pretty verbose and it shouldn't
be too much trouble to take a good guess at what is going
on.
You guys are already at this stage since you are compiling
the tree with what I would guess are mostly hollow functions
and classes.
From this point on you start implementing features. The
first big hurdle is to get a window up and running, which
means that the logic behind the frame and app classes is
sorted out. This will involve dealing with mainly (but not
exclusively) four groups of files:
af/xap/mac/*Frame.*
-> Cross application level code to actually create the
window, instantiate the menubars, instantiate the toolbars
with a call out to the application level code to actually
create a work area.
af/xap/mac/*App.*
-> Cross application level code to do application wide
set up. In general I haven't had to do much here. You
might have to do your string/preference processing here
or in the application App code.
wp/ap/mac/*Frame.*
-> Application specific level code to create the specifics
in the work area of the word processor. We bind the
rulers and the status bars in here and also create a raw
drawing region for the actual document. This raw drawing
region is used by the graphics class to do the toolbars
as well.
wp/ap/mac/*App.*
-> Application specific level code to initialize the application.
Not much has to be tweaked in here for me so far.
From there you just will start hitting things that you can or
already have stubbed out for the most part. I would suggest
getting the main frame laid out ... then have each region
a seperate blob to make sure that the spacing is correct
and that re-sizing works.
Once the layout works I generally start with the menus (which are
usually fairly straight forward to implement) then the toolbars
(the biggest pain here is layout and the fact that you have to
translate the XPM into a local image format to display the buttons.
From here I go and fill in the specifics of the graphics class.
Once that is done you have something that is starting to look
like it could be a word processor (other than the fact that you
can't do anything with it). You should even be able to load
up files from the test directory.
Congratulations, you have an AbiWord reader.
--- Breath Deeply ---
Next I go ahead and tackle the keyboard input (which is pleasantly
easy!) leaving off the Ruler and Status bar. Once this is working
in theory (assuming that you have completed the above steps)
you should be able to now type, use the toolbar to change fonts
and use the keyboard to select, cut and paste.
From here I diverge a bit and don't have so much a rote pattern.
I go through usually and create the dialog class so that you can
use the file/save/open dialogs to interact with the program and
to get error messages about things that aren't developed yet.
I add mouse support (almost as easy as keyboard support!) after
that, then the final thing for the main interface to make it look
complete is the Rulers (which should come for free after you do
the Graphics class and munge a little bit of code from you mouse
stuff).
Once this is done you actually have a working functional AbiWord.
--- Exhale ---
Without a doubt the most painful part (well for me) is implementing
the dialogs. You need to stay in sync both look and feature wise
with the other platforms (see the shots directory in CVS). Our
dialogs tend to come in spurts ... and will be a growth area for
the future development I'm sure.
Long post I know ... but if anyone has any questions about porting
AbiWord on other platforms I'm happy to help.
Thomas
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
This archive was generated by hypermail 2b25 : Fri Feb 25 2000 - 15:27:37 CST