Cocoa differences

Hi Y'All,

So much e-mail! Where to start?

Okay, first, I confess that Cocoa and AbiWord maintenance were (and
continue to be) a steep (though thoroughly enjoyable) learning curve
and I have often chosen very bad ways to fix things that I am still on
occasion un-fixing. Being pretty much the sole developer for the
platform for the last 6 months means that I have often had to delve
into parts of AbiWord's code that I have prayed for years (with
excellent reason) that I would never have to set foot in.

Platform Consistency

Until recently (and for a couple of years previously) I didn't have
access to other platforms so by and large I've been doing what made
sense for the Cocoa-FE without a good reference to the other platforms.
The Options dialog is an excellent example of a dialog that is (a) a
mess of code, and (b) inconsistent with the snap shots in CVS. (More
about this later.)

Am I deliberately trying to make the OSX port different? Well, by
necessity it is different in many ways, but in general I try to resist
changes that conflict with xp methodology. There's nothing that
frustrates me more than having to put #ifdef MAC_TARGET_COCOA (or
whatever) in xp code.

Many of the problems have arisen because the Cocoa port is the only one
that doesn't require the existence of a current document, and the only
one in which the toolbars are not attached to the document window
(although this is a point of some controversy). Most of the rest have
been caused by the UI zealotry of Mac users - I have been using a Mac
for 5 years now and I wasn't aware of 90% of the "bugs" that have been
brought to my attention.

Cocoa provides a number of (I believe) unique interface elements that I
would like to use, elements which are familiar to Mac users but not
available to the other platforms, or at least not easily available. So
far I haven't really tried to use these, because AbiWord's consistency
is important, and because there are far less controversial "fixes"
still to be made.

Stable vs Head

I have been working on stable because it still isn't as polished as we
would like, and thus has a way to go before the users are happy. On the
other side of this, I have as far as possible tried to avoid xp code.

Of course, if I have added features that you would like to make
cross-platform, then I'm very happy to work on an xp solution. By and
large, when working in Cocoa code I'm usually quite happy working
within the Cocoa paradigm because it simplifies matters.

Tool Palette

MSWord for Mac has a palette and I find it very useful, and also at the
time the Cocoa-FE toolbar was in dire need of fixing. So I made this a
little project, and I think it has been mostly a success. Now that I
have the plug-ins working, I can see how I could turn this into a
plug-in, and indeed I may even do that at some point.

Format Frame Dialog

A classic example of looking at the code and the expected functionality
and seeing what it should do, and what IMO was the best solution rather
than necessarily what was being done elsewhere. I think it works well,
and plan to do something similar for Format Cell.

I wasn't aware of providing different functionality, although I was
aware of implementing stuff that had apparently been neglected.
However, I also provided a clean code API in the xp class to make it
easy for the other platforms to update. I accept that I misunderstood
the nature of the dialog on the other platforms, but I continue to
believe that the previous MSWord-like behaviour was (and is) awful.

Options Dialog

Wow, what a mess. I created this new Options dialog because the current
one is in desperate need of a rewrite. I hadn't really intended it for
stable, but it turned out to be a lot more stable than the real stable
dialog so I switched it over. In case people missed it, I proposed
working on a new Options dialog for 2.4, and this is the basis for what
I planned. (The underlying code for the new Options dialog is xp, but
currently commented out.)

Cocoa Plug-Ins

We have been talking about doing a C API for ages now. I thought it
would be interesting to try to develop an Obj-C API (which could,
perhaps, be turned into a C API later) because this works well on OSX.
Whether it's strictly necessary, I don't know, but it's certainly
interesting.

The New Font Menu

Why does it have the same name? Because the localization exists, and
the purposes are clearly different. Does it need to be in the main menu
like that? Probably not - it could even be optional. Does it provide
useful functionality? Certainly. Am I flexible? Of course. I welcome
suggestions, and may even see if I can get uwog's preview to work
instead.

I don't like the idea of reverting this, because I think it adds
something very useful. I am quite happy to improve it, in whatever way.

Fun, fun, fun,
Regards, Frank
:-)
Received on Mon Mar 28 22:11:59 2005