Comments on: Mac OS X Cocoa Plans
I want to clarify our plans with regard to OS X development.
Simply stated:
- For REBOL 3.x, we plan to use Cocoa. (More below.)
- For REBOL 2.x, we do not plan to port to Cocoa at this time.
Currently, for OS X, REBOL 3.0 uses the Posix model at the C library level. However, for the rest of the environment, we would like to use Cocoa.
Although building a basic Cocoa app is fairly easy, our integration with the R3 core will be a more bit complicated. Cocoa takes over the entire application model in a broad way, but REBOL applications use their own OS independent application model (a bit similar to how web pages or Flash apps work).
However, we are encouraged by the fact that various scripting languages are now running in Cocoa. Also, a lot of the effect of Cocoa really applies to the outer layer of REBOL, it's Host environment. We hope we can isolate it properly.
So, if you have deeper experience with writing OS X Cocoa code, and you want to help bring REBOL into that domain, please contact me, and let's figure out the details to move forward with it.
15 Comments Comments:
croquemitaine
12-Mar-2009 4:01:56 |
Opendarwin means bsd meaning 90% compatible with Linux.
Would you do something around Darwin? | Kaj
13-Mar-2009 8:06:08 |
That's just the POSIX layers. Most of that is already implemented in R3. What's needed now is interfacing with higher-level layers, such as interfacing the graphics system with Cocoa on OS X. | Ratio
15-Mar-2009 14:06:44 |
Carl,
please NO cocoa.
| Henrik
15-Mar-2009 15:13:40 |
Ratio,
Cocoa is the defacto standard API under MacOSX and it will be even more so in future versions of MacOSX. Without it, REBOL 3 will not integrate properly into MacOSX. | Carl Sassenrath
18-Mar-2009 20:07:21 |
Ratio, no Cocoa? Why do you say that?
It may be possible to support both Cocoa and a plain Posix (BSD) version, but that will be determined not by me, but by who wants to write and support that code.
| Ratio
19-Mar-2009 20:10:17 |
Hi Carl,
thanks for your question re Cocoa.
Really, I do NOT think we need more than just ONE good GUI.
We already have best GUI capabilities in REBOL. Remember e.g. the marvelous readmail.r by Phil Bevan!
Other things like Cocoa, KDE, GNOME, Windoze, HwGui, FiveWin etc.pp. (about thirty such things in LINUX) are not needed complexities as you correctly would put it.
Personally,
since decades I am 'suffering' on programming and searching usable systems for my accounting application first written in assembler and C on CBM.
I never saw things like your ingenious REBOL approach. Not even in all the LINUX flavours - nowhere!
REBOL alone should be developed !!
REBOL is the OS of the future.
Cheers, Ratio
| Henrik
20-Mar-2009 1:13:57 |
Ratio,
Cocoa has nothing to do with what GUI will be used in REBOL. Cocoa is the MacOSX system programming API used in order to access menus, Exposé, the dock, fonts, general window handling in a proper way, to create a REBOL that behaves properly under OSX. It also accesses file handling, networking, audio, hardware graphics acceleration and various kernel features like multi-core processing.
If REBOL 3 will ever get on the iPhone, the only way to do that is through Cocoa.
REBOL 3 won't be using the Quartz drawing engine or the Aqua user interface directly.
For "outsider programs" like REBOL that isn't made in Cocoa, you need to adhere to a larger set of rules than you need to in Windows, and this integration is necessary for giving the Mac community a good version of REBOL.
The original question was whether to use Cocoa or Carbon. REBOL 2.6 uses Carbon, and Apple are now busy getting rid of it in future versions of MacOSX.
REBOL/View 2.6 under OSX uses Carbon and does not adhere to the rules and is a pain to use. | Luis.
20-Mar-2009 2:24:04 |
Hiya,
I may be wrong, but I think his comment (Ratio) has more to do with keeping 'appearances' consistent than opting for a 'native' API call to OS functions, such as windowing, which may be seen as adding to the Rebol 'list of things I should know'. Essentially: Not really keeping the cross-platform ethos consistent, by dropping the Rebol 'look and feel' (when it comes to GUI options).
I don't know how feasible it would be to include a switch that translates the Rebol GUI to the native platform GUI, which would then present further options if native OS functions are then required (such as sheets in OS X).
I know Cocoa is more than the GUI, I'm stating here what I feel he is trying to put accross.
Cheers,
Luis.
| -pekr-
20-Mar-2009 8:28:51 |
Luis - afaik REBOL GUI will not translate to native OS widgets. It is just that underlying layers will use Cocoa elements to render ... | Ratio
21-Mar-2009 17:23 |
Hi folks
Sure, Cocoa is not just another GUI. But what else does it provide?
Henrik mentioned things I would be inclined to see as, in a wide sense, "driver problems".
Things like drivers, interfaces, protocols should, in my opinion, not be inserted into the REBOL kernel.
C by the genius Dennis Ritchie at the Bell Telephone Laboratories followed the same philosophy.
We load drivers/interfaces just as needed.
My program does these things every day thousand times.
Since decades
I am responsible for a banking/accounting application, used on servers and clients.
First my program was tiny and very fast, written in assembler and C.
But since, for compatibility reasons, I had to switch to Windoze I had to produce and got megabytes
of ridiculous source and slow executable code. The Windoze SDK is just a mess.
In the moment I am using HwGui and xHarbour - a clone of the famous CLIPPER.
But I do not use their ridic "xBase" language :-((
We should, as in REBOL, strictly adhere to function syntax.
Function-syntax
is internally always applied - and easy to learn:
(1) Function name,
(2) any parameter/s,
(3) any return value/s
That's all we must know about functions!
If we do not like a function we will not use it or write our own. :-)
Ratio
| Ratio
21-Mar-2009 17:28:27 |
Hi Carl
I beg your pardon.
Calling Windoze from REBOL works fine.
Calling REBOL from Windoze with parameters is still a problem.
If you want programmers of running Win32 applications change to REBOL - yes, you should! -
REBOL should document some migration hints in a step-by-step-way.
e.g.:
I have problems to call REBOL with its wonderful REQUEST function's from my Win32 application.
So far I didn't succeed to transfer the parameters correctly.
You certainly know where the problem arises.
I don't. I tried it with arrays, blocks, a special REBOL function etc.
Ratio
| Henrik
22-Mar-2009 2:06:32 |
Ratio,
I think I see what you mean, but:
Sure, Cocoa is not just another GUI. But what else does it provide?
Henrik mentioned things I would be inclined to see as, in a wide sense, "driver problems".
Things like drivers, interfaces, protocols should, in my opinion, not be inserted into the REBOL kernel.
The REBOL kernel will not bloat, due to the new device model, which abstracts OS interfaces away from the kernel. Read about it here:
http://www.rebol.net/r3blogs/0087.html
REBOL will interface the underlying OS in an open way that lets you write the code necessary to, for example, open a native file requester or access an already existing audio driver on the operating system.
These "driver problems" do not exist inside of REBOL 3, so the REBOL 3 executable stays small. It's simply about using the already existing resources in the OS where they are necessary or make sense.
It doesn't matter whether it's on Windows with whatever is used there or on MacOSX with Cocoa. The model is the same and it the right model to use.
One more argument for Cocoa: Carbon 64-bit has been dropped and only Cocoa is able to use the 64-bit features of MacOSX in the future.
So, please bring on Cocoa. :-) | Ratio
22-Mar-2009 22:08:46 |
Though I personally never missed Cocoa, you might be right, Henrik.
I detected REBOL just a couple of weeks ago when I was searching for an easy to use translation routine: text => html.
Found Makedoc. Again Carls outstanding work (has btw a bad and misleading 'clone' in Germany, unihagen).
I was and I am excited reading Carls philosophy and testing his ingenious REBOL system.
What I really regret:
Carl, as almost each creative genius, forgot and forgets the marketing.
Migration is the keyword in this respect.
We find nothing about this for each programmer crucial problem. Nothing in all the otherwise extremely well and carefully written documentations.
I am btw not convinced that we need instead of that a REBOL 3.0
Ratio
| Ratio
28-Mar-2009 19:36:29 |
Commercial
pogrammers are not interested in music, games, photos and other, in their view, more childish things.
Commercial pogrammers need just a good GUI interface. REBOL and the add-on RebGUI seem to be perfect in this respect.
But most important:
Commercial pogrammers need a good DATABASE interface.
I tested in REBOL several user contributed interfaces to different flavours of SQL (MySQl, SQLite, Uniform.
Saw btw nothing about Oracle or Clipper/xHarbour, I am using in the moment for my accounting apl.)
I feel that Carl better directs his valuable attention to database management.
I am also missing, on all REBOL sites, a donation button.
Ratio
| Luis.
30-Mar-2009 1:10:23 |
'Commercial pogrammers are not interested in music, games, photos and other, in their view, more childish things.'
That's bread and butter for a lot of us (although it may not be through Rebol).
I agree with the database comment, even games use databases!
Cheers,
Luis.
|
Post a Comment:
You can post a comment here. Keep it on-topic.
|
