Re: Cocoa differences

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

when did I start over the Cocoa port ???? 2001.
And I have been alone for that long time, fighting against bugs, code
changes in XP land, etc. I understand your pain.
And I must apologize to not have been able to take over again, up to
speed in the last month.

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

Doesn't it build using Gtk on MacOS X ? I haven't tried myself as I have
plenty of Linux to try on.

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

I have tried myself to reduce that to a very strict minimum.

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

I have worked toward that XP wise. It took more time, but I wanted it to
work in XP.

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

I must not agree with that way of doing things. The feature should be
thought XP first. Otherwise it will make things harder.

[...]

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

My dialog framework, that I have still to update the doc for, is
intended to fix most of these issues and allow rewriting that dialog
*simply*, for all platforms.

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

It is not necessary at all for AbiWord. I'm even more tempted to say
that it would be a danger to see plugin that can't be easily made to
work on other platforms.

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

In STABLE, it MUST BE reverted. Period. It is bug fix release, this kind
of UI change is stricly out of scope.
In HEAD, then sure we can discuss this and make it work XP wise. But
having 2 "Font" menus is surely completely wrong.

One of the solution would be to have a "Font >" menu to choose the font
and a "Characters..." menu item to do what the font dialog currently do.

Hub
Received on Mon Mar 28 22:29:27 2005