Talk:Cocoa for EiffelVision2 - Revision history

Manus: /* GOBO */

2006-10-31T19:14:59Z

‎GOBO

Schoelle at 16:19, 31 October 2006

2006-10-31T16:19:06Z

Dfurrer at 09:18, 27 October 2006

2006-10-27T09:18:50Z

Dfurrer: /* Cocoa, Carbon ??? */

2006-10-27T09:17:43Z

‎Cocoa, Carbon ???

Dfurrer: /* Mac Specifics */

2006-09-03T13:40:02Z

‎Mac Specifics

Dfurrer at 14:59, 15 August 2006

2006-08-15T14:59:15Z

Bayt: Moved Dfurrer's inputs here, reorganized layout and added cocoa link

2006-04-18T19:56:41Z

Moved Dfurrer's inputs here, reorganized layout and added cocoa link

Bayt at 06:59, 12 April 2006

2006-04-12T06:59:21Z

Bayt at 06:42, 12 April 2006

2006-04-12T06:42:00Z

Bayt at 06:32, 12 April 2006

2006-04-12T06:32:17Z

New page

Maybe we should not target Cocoa, but carbon, just like SWT:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.carbon/
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.carbon.macosx.ppc/

could serve as inspiration for the backend.

← Older revision		Revision as of 19:14, 31 October 2006
Line 16:		Line 16:

	Which GOBO version is required exactly? There is quite a big difference between GOBO 3.4 and GOBO CVS. (schoelle, 31.10.2006)		Which GOBO version is required exactly? There is quite a big difference between GOBO 3.4 and GOBO CVS. (schoelle, 31.10.2006)
		+	I would say the Gobo 3.4 included in EiffelStudio 5.7, but the Gobo CVS should also work as far as I know.--[[User:Manus\|manus]] 20:14, 31 October 2006 (CET)

← Older revision		Revision as of 16:19, 31 October 2006
Line 12:		Line 12:
	=Cocoa or Carbon?=		=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.		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.
		+
		+	= GOBO =
		+
		+	Which GOBO version is required exactly? There is quite a big difference between GOBO 3.4 and GOBO CVS. (schoelle, 31.10.2006)

← Older revision		Revision as of 09:18, 27 October 2006
Line 12:		Line 12:
	=Cocoa or Carbon?=		=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.		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.

@@ 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.
-=Cocoa, Carbon ???=
+=Cocoa or Carbon?=
-* Maybe we should not target Cocoa, but carbon, just like SWT: [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse%20SWT/carbon|carbon example in swt] could serve as inspiration for the backend.
+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.
-* Info for [[http://developer.apple.com/cocoa|Cocoa]]
-* Alternatively (and probably much easier) one could also make EiffelVision use the native GTK+ port instead of the X-version. But the state of Gtk+-Cocoa is unclear. ([[User:Dfurrer|Dfurrer]])
 =Howto=

@@ Line 1: / Line 1: @@
 =Mac Specifics=
-==Several Platforms==
+== 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==
+== Single Menu Bar ==
-Unlike 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. ...
+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)
 =Cocoa, Carbon ???=

← Older revision		Revision as of 14:59, 15 August 2006
Line 1:		Line 1:
		+	=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 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. ...
		+
	=Cocoa, Carbon ???=		=Cocoa, Carbon ???=
	* Maybe we should not target Cocoa, but carbon, just like SWT: [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse%20SWT/carbon\|carbon example in swt] could serve as inspiration for the backend.		* Maybe we should not target Cocoa, but carbon, just like SWT: [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse%20SWT/carbon\|carbon example in swt] could serve as inspiration for the backend.

← Older revision		Revision as of 06:59, 12 April 2006
Line 2:		Line 2:

	could serve as inspiration for the backend.		could serve as inspiration for the backend.
		+
		+	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.