[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re(2)- MCL Direction

I read your reply with interest.  I have a little to add on your technical
comments,  but one area on which I would like to focus is that of organising
developers using MCL.  I am aware that Harvey Alcabes tried to organise a get
together some months ago; I suspect, from the lack of any report or further
news, that the response was limited.
You will probably be aware that the MacApp Developers Association is currently
considering its future, and one of the options (which I particularly have been
pursuing) is to embrace more OOP systems, including MCL and Prograph, in SIGs
within MADA.  There are many advantages to this, not least of which is the fact
that MADA enjoys good relations with Apple, a position which any MCL group also
needs.  MADA also has offices, staff and finances, and quite a few members
(like myself) who use both MacApp and MCL.
Harvey and his team do a sterling job, not only in continuing to develop MCL in
directions which are popular, but also in responding well to requests for help
here and on AppleLink.  I am keen that we (MCL users) can get organised so that
our views can be represented to Apple in a coordinated fashion, and not as a
series of disparate messages, ranging from the amicably helpful to a few which
have bordered on the offensive (in my opinion).  This is not to dilute users'
opinions, but to bring them together and enable Apple to deal primarily with
one main point of contact.
*IF* (and I say again, *IF*) MADA does move in that direction, and we do
establish an MCL SIG within it, would that not help such enquiries, which I am
sure all of us share in one way or another?  I personally am very keen to see
organisations like MADA become aggressively self-helping too - if Apple cannot
devote resources to documenting aspects of its own products, then I would like
to see MADA (or similar) doing the job for them - much in the way that MADA did
with its excellent MacApp Condensed Reference (by Robin Mair and Jeff Alger).
At the moment, anyone attempting this is really out on a limb, but within a
proper organisation, and with the right protocols with Apple, I think this
could be beneficial for all concerned.
Oh - and I too would be very interested to hear the official Apple responses to
the questions.  For the record, I can offer my opinions:
1.  Standalone apps will work properly with MCL 2.0 final, I gather.
Currently, you can make them, but
:excise-compiler t
only disables the compiler and does not strip it.  Still, it makes it
worthwhile buying Stuffit Deluxe, so that you can ship the app on a single
2.  Yes, I too understood that the new improved GC would be in MCL 2.0 final.
3.  From what I hear (and see) of MacApp 3.0/C++, MCL apps are actually likely
to outperform them in most respects, particularly the human interface, unless
something dramatic happens with MacApp 3.0 final :-) - and think of the savings
in development time and maintenance with MCL over anything C++!
4.  I do not actually miss a large Class Library with MCL, but then I have not
yet written an ordinary commercial app with MCL yet, at least not in the way
that I have with MacApp 2.0.  I suspect that this is something which could be
done collaboratively within an MCL SIG, by bringing together various existing
fragments and building the missing bits.  The problem is that folk then want
portability to other platforms, in which case CLIM would be a better option to
start with.
5.  I agree with the need for a full Class Browser - this could easily be a SIG
project too, unless Apple have it planned.
6.  Agree.
7.  Hmmm.  I suspect that these are rather individual - for instance, I have my
way of handling the redrawing of objects within views, which is based on my
experience with MacApp, but others do it very differently.  I think the big
difference with MacApp is that MCL is not a complete Class Library, surely, and
thus such matters are really up to the user.
8.  Agree with Steve's comprehensive answer.
9.  I think that Steve may have missed the point on this.  As a European, with
customers throughout Europe, non-resource based dialogs and menus are a pain
when it comes to localisation.  However, even with resource-based ones, the
tools currently available are primitive, and most good commercial localisation
is far from easy or cheap.  Perhaps a tool to help with this would be another
useful SIG project.
10.  From all that I have seen, Apple is fully committed to MCL as a serious
and complete development environment for today and the future, and for
delivering high-quality commercial applications.  Long may it continue!
Regards, Howard.