Difference between revisions of "Talk:Cocoa for EiffelVision2"
(→Mac Specifics) |
(→Cocoa, Carbon ???) |
||
| Line 10: | Line 10: | ||
On other platforms many controls have a very simple design and can thus support colorization, i.e. changing the background- and foreground color of a control for a great deal of different controls. On the mac this is not the case since controls are a piece of artwork and actually I don't see a reason for supporting this, expect for a few controls like the label and the textfield of course. | On other platforms many controls have a very simple design and can thus support colorization, i.e. changing the background- and foreground color of a control for a great deal of different controls. On the mac this is not the case since controls are a piece of artwork and actually I don't see a reason for supporting this, expect for a few controls like the label and the textfield of course. | ||
| − | =Cocoa | + | =Cocoa or Carbon?= |
| − | + | We have made our decision for Carbon because since it is a C-API (not Objective C) it is easier to interface from Eiffel and even though Apple recommends developing new applications in cocoa there are no plans to drop carbon and it is still actively developed. | |
| − | + | ||
| − | + | ||
=Howto= | =Howto= | ||
Revision as of 01:17, 27 October 2006
Contents
Mac Specifics
Several Platforms
Mac OS X currently supports at least four different processor types (that is a 32 and 64bit version of both, ppc and intel processors). Apple provides tools for compiling for all architectures and putting it all in a so called fat binary or Universal Binary. I think we should have single, simple EiffelStudio distribution that runs on all of these and has the possibility to create fat binaries from the eiffel programs it builds.
Single Menu Bar
Unlike known from other GUIs in Aqua there's just a single menu bar at the top of the screen and that is shared between all windows of all applications. Our current plan is to use this standard menu bar on the top (an absolute must imo) but change it with whichever window is in the foreground if necessary. (Typically a Mac OS application only has a single menubar - not one per window)
Colors
On other platforms many controls have a very simple design and can thus support colorization, i.e. changing the background- and foreground color of a control for a great deal of different controls. On the mac this is not the case since controls are a piece of artwork and actually I don't see a reason for supporting this, expect for a few controls like the label and the textfield of course.
Cocoa or Carbon?
We have made our decision for Carbon because since it is a C-API (not Objective C) it is easier to interface from Eiffel and even though Apple recommends developing new applications in cocoa there are no plans to drop carbon and it is still actively developed.
Howto
The basic approach would be:
- to write a very simple Vision2 application only showing a window.
- then we will have to write all implementation classes for the Vision2 widgets that will use the cocoa or carbon widgets internally
- these will be empty at the beginning and then slowly filled
- then one would start from the Vision2 event loop and try to fill the first implementation class, the one for the window probably
- and from there one would go to the other widgets
This is a very interesting project as it unifies many different widget toolkits, you learn lots about the widget toolkit on OS X. But it is also tricky because the widget toolkit on top of which you are also has bugs that you have to work around. For example in carbon the Bevel button in OS X does not display correctly when it's height is set to be smaller than 20 pixels. So if you provide an interface to that button, you would have to work around that.
