Re: Cocoa differences

> 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 would not dare to argue that you are deliberately trying to make the
OSX port different, just that the differences should be communicated
beforehand.

Heck, maybe the XP code is just wrong, and should be fixed to accomodate
the Mac port better.

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

Then why for example 'forking' the whole dialog, instead of fixing the
XP code to not make too much wrong assumptions?

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

You deserve a lot of credit for the task of dealing with mac users,
really :-|

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

I you or anyone else discusses it on list first, we can see if there is
any good reason not to use those elements (same holds for other
platforms). As long as it is mentioned or discussed, so other developers
are at least aware of it, I see no problems in advance.

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

I'm well aware of that, and thus have never refused/reverted any OSX
patch to STABLE. This would only hinder the speed in which the OSX port
is maturing, which has been remarkable over the last few months.

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

Would be nice to document the changes somewhere (not of OSX
specifically, but for Win32 and Unix as well). As I and any others don't
have access all platforms, such a list could spark ideas about what
could be made XP, and what should be left in 1 platform alone.

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

Yep, this is a very nice addition indeed. Would be nice being a plugin,
but I couldn't care less really.

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

It was *not* neglected (i think you are referening to border styles).
You are using code that is broken as h*ll, and should/will be replaced
in the future. To avoid backwards compatibility problems then, we didn't
use the broken code in the first place.

> However, I also provided a clean code API in the xp class to make it
> easy for the other platforms to update.

This is very much appreciated, and is exactly "the proper way to do it".

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

Agreed, but you made the change without notifying anyone (at least not
in a way that I noticed), so I didn't even know i _could_ update the
Unix dialog.

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

AFAIS, it is a _huge_ task to create an API with all the functionality
that can currently be used. I think using swig is a better approach than
to spend a lot of time on this. Dom could comment better on this though,
and of course, it is your spare time.

>
> 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 would love to see 'my' work on OSX as well, given that it can be
adjusted if needed to suit your needs. Would reduce the code size and be
better maintainable.

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

The functionality is definately needed, we agree on that. I just didn't
see the need for rewriting it *again* (win32 also did that for no
apparent reason (except that the XAP_Preview_whatever class needed to be
implemented on Win32).

Don't take any of this personally. We all can improve our work in one
way or the other. Given the wonderfull response we continue to get on
the OSX port, we can only thank you and hub.

Cheers,
  Marc
Received on Mon Mar 28 22:39:03 2005