Sorry, previous E-mail was sent prematurely and contains an incomplete sentence. Ignore it and read only this one.
On 26/06/2011, at 10:42 , Bernard Desgraupes wrote:
I'd like to make a proposal concerning the future development of the
This is good. However, I propose to distill two separate issues out of this:
1) Making AlphaX open source
2) Using Cocoa or Objective C as the new basis
I am fully in favour of making AlphaX open source and I trust, that we can easily agree on this.
The 2nd issue is IMHO a bit more complicated, as I try to explain below:
Currently AlphaX is an application which entirely relies, after two
years of rewriting, on the Carbon framework and on the Carbon Events
model. Alas the Carbon technology is now considered obsolete by Apple
which just maintains it for compatibility or legacy reasons and in
order not to rule out many applications which have adopted this same
model. But it has been stated clearly that no future development will
be made in this direction and in particular there will never be a
64bits version of Carbon. The question even arises to know when Carbon
will be completely dropped (it is confirmed that it is still present
in the forthcoming Lion system, but what after that): so there is a
risk that in some time Alpha won't run on future versions of the system.
On the contrary Apple insists on having developers switch to Objective-
C and to the Cocoa framework and puts all its energy in this new path.
So I think it is time to bite the bullet and to go Cocoa. This implies
a rewriting from scratch of the source code. This is obviously the
condition sine qua none to keep in synch with new future technologies
and, for example, to be able to develop a version of Alpha for the iPad.
I am happy with biting bullets as long as we don't joke on it. I mean we need a good chance and realistic perspectives to be able to really accomplish this. Who all are helping Bernard on that? Of course, Bernard, I greatly appreciate your immense capabilities, enthusiasm etc. I really do. But I would feel better, if not too much burden will rest on your Atlas shoulders.
Then I'd like to draw your attention to the fact that Objective C is not good enough to move to the iPad. The basis is quite different (Mac OS X vs. iOS). While it is true that underneath iOS is nothing else than a Unix, to access it directly and hereby hacking/circumventing iOS is not the way to go and invites only troubles.
Moreover, I have an iPad but I doubt I would use it ever for any heavy editing with AlphaX. This is exactly where I have to resume work on my Mac. For simple viewing of source code or changing a tiny little bit, we have already nice text based Apps such as SimpleNote. If your desire should be to use AlphaX as a tcl engine to do tasks in the background, that's an entire different thing. But since iOS gives you no full file system, I doubt there are many things one could do with such AlphaX services.
Here is now my proposal: as I have already suggested in the past,
Alpha would really benefit from being an Open Source project. If it
were an Open Source modern project, I'm sure a lot of people would be
attracted and ready to contribute because it is a really powerful and
fascinating tool. So I tpropose we start a new project to write from
scrap a new core for the already existing and open sourc'ed AlphaTcl
library. This is an approach which is comparable to the AlphaTk
project in its time: this would be an independant project written in
another language (Objective-C) and relying exclusively on the Cocoa
framework and the Quartz technology for drawing.
I'm ready to undertake such a challenge and, as a matter of fact, I've
already led some experiments and made some headway. I have a minimal
Cocoa application embedding the Tcl framework and starting AlphaTcl.
It also embeds the ICU framework to have a complete support for
Unicode and I have implemented a new [icu] core command to deal with
all the Unicode-related manipulations.
I agree but incidentally, I regularly enjoy AlphaX not being unicode. I regularly encounter utf encoded texts that won't be imported by BibDesk. AlphaX is the quickest remedy for that, precisely because it does **not** work with unicode. If AlphaX is going unicode, I hope there will be a clear philosophy and converting means for that, similar to what we currently have with respect to Mac, Unix, and IBM PC text files.
This new project, which could be named AlphaCocoa, might be installed
on SourceForge to make it accessible to everybody. This would be a
great opportunity of redesigning the interface, discussing new ideas,
making suggestions, and probably also rethinking the structure of
I also don't like the name AlphaCocoa. AlphaX was fine with me because Mac OS X is more likely to stay a bit with us (I hope at least ;-) ). If a generic new Alpha should emerge (unification with AlphaTk), the old name 'Alpha' might be quite appropriate, leaving a phase of branching behind us.
With respect to the implementation philosophy of a Cocoa version of AlphaX. I suggest the following balancing:
1) Minimum use of Cocoa, basically confined to the GUI aspects (use of Interface Builder) and event control
2) Rest of code in C as much as possible, reusing current AlphaX code, basically only abandoning of Carbon event handling
3) Making good use of AlphaTk by relying as much as possible on Tcl/Tk seems to me to be a quite a good and possible fruitful idea, inasmuch this helps to minimise the recoding effort of the binary kernel (as described under point 2) above). Vince, nice to hear from you: Is really everything of AlphaTk in Tcl/Tk, or is there not some other "binary" kernel? Sorry, have never looked at the source code. If there is some binary kernel, what is the ratio?
I'd be glad to hear opinions about these ideas.
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 221-4657 mobile
Make it as simple as possible, but distrust it!