Vision4Mac Documentation - Revision history

Dfurrer: /* setup_layout */

2007-05-19T11:05:13Z

‎setup_layout

Dfurrer: /* child_has_resized (a_widget: EV_WIDGET_IMP; a_height, a_width: INTEGER) */

2007-05-19T11:04:45Z

‎child_has_resized (a_widget: EV_WIDGET_IMP; a_height, a_width: INTEGER)

Upeter at 14:13, 18 May 2007

2007-05-18T14:13:07Z

Manus: /* Style */

2007-03-30T17:16:36Z

‎Style

Dfurrer: /* Guidelines */

2007-03-30T14:58:26Z

‎Guidelines

Dfurrer at 14:03, 30 March 2007

2007-03-30T14:03:18Z

Manus at 19:30, 31 October 2006

2006-10-31T19:30:36Z

Manus at 19:29, 31 October 2006

2006-10-31T19:29:03Z

Dfurrer: databrowser

2006-09-03T13:28:49Z

databrowser

Dfurrer: /* Object creation */

2006-08-14T20:53:31Z

‎Object creation

@@ Line 106: / Line 106: @@
 ===setup_layout===
-. reorganize the layout of the container
+# reorganize the layout of the container
-. do setup_layout on every child
+# do setup_layout on every child
 ===layout===
 reorganizes the layout of the current container.

@@ Line 100: / Line 100: @@
 Class EV_CONTAINER_IMP (which is an ancestor of all containers) has three main features to keep this structure propre:
 ===child_has_resized (a_widget: EV_WIDGET_IMP; a_height, a_width: INTEGER)===
-. save old minimum_sizes
+# save old minimum_sizes
-. calculate the new minimum_sizes from a_height and a_width. A_height means, that a_widgets minimum_height is now a_height larger. This calculation differs for the various containers.
+# calculate the new minimum_sizes from a_height and a_width. A_height means, that a_widgets minimum_height is now a_height larger. This calculation differs for the various containers.
-. If Container is a viewport or a scrollable_area then setup_layout
+# If Container is a viewport or a scrollable_area then setup_layout
-. If not a viewport or scrollable_area then do parent.child_has_resized (current, (minimum_height - old_minimum_height), (minimum_width - old_minimum_width))
+# If not a viewport or scrollable_area then do parent.child_has_resized (current, (minimum_height - old_minimum_height), (minimum_width - old_minimum_width))
 ===setup_layout===

← Older revision		Revision as of 14:13, 18 May 2007
Line 92:		Line 92:

	This is only an experimental idea so far, but it seems to work out quite okay. So the idea I currently have is the following: It would be nice to have a heavily platform specific class which supports all the neat OS X features and interacts directly with the wrapper. The Vision conrols could then transparently use that other widget. Now, if an experienced user (a Mac user :)) wants to write something OS X specific, he could also use that class directly.		This is only an experimental idea so far, but it seems to work out quite okay. So the idea I currently have is the following: It would be nice to have a heavily platform specific class which supports all the neat OS X features and interacts directly with the wrapper. The Vision conrols could then transparently use that other widget. Now, if an experienced user (a Mac user :)) wants to write something OS X specific, he could also use that class directly.
		+
		+	== Container Structure, embedding and removing ==
		+	The structure of the widgets in a program is a tree. The root of the tree is a window, the leafs are primitives and the inner nodes are containers.
		+
		+	If a primitive or a container widget changes the minimum size (for example by adding some text to a button or by extending a container) this change has to be propagated to the next ancestor who is a viewport, a scrollable_area or a window (only this containers do not change their minimum_sizes even if a child has changed their minimum size). All elements in the subtree of this container, have now to reorganize their layout. We do this by recursion.
		+
		+	Class EV_CONTAINER_IMP (which is an ancestor of all containers) has three main features to keep this structure propre:
		+	===child_has_resized (a_widget: EV_WIDGET_IMP; a_height, a_width: INTEGER)===
		+	1. save old minimum_sizes
		+	2. calculate the new minimum_sizes from a_height and a_width. A_height means, that a_widgets minimum_height is now a_height larger. This calculation differs for the various containers.
		+	3. If Container is a viewport or a scrollable_area then setup_layout
		+	4. If not a viewport or scrollable_area then do parent.child_has_resized (current, (minimum_height - old_minimum_height), (minimum_width - old_minimum_width))
		+
		+	===setup_layout===
		+	1. reorganize the layout of the container
		+	2. do setup_layout on every child
		+
		+	===layout===
		+	reorganizes the layout of the current container.

← Older revision		Revision as of 17:16, 30 March 2007
Line 14:		Line 14:

	a: INT or a : INT		a: INT or a : INT
		+	--[[User:Manus\|manus]] 19:16, 30 March 2007 (CEST) It should be ''a: INTEGER''

	== Object creation ==		== Object creation ==

← Older revision		Revision as of 14:58, 30 March 2007
Line 8:		Line 8:
	Where should events be registered? -> make (for no reason)		Where should events be registered? -> make (for no reason)

		+
		+	=== Style ===
		+
		+	ret: INTEGER or err as return value?
		+
		+	a: INT or a : INT

	== Object creation ==		== Object creation ==

@@ Line 1: / Line 1: @@
 [[Category:EiffelVision2]]
 [[Category:Macintosh]]
 == Object creation ==
 The way classes will be created is somewhat special in Eiffel Vision. Take a look at EV_ANY (, EV_ANY_I)

← Older revision		Revision as of 19:30, 31 October 2006
Line 1:		Line 1:
		+	[[Category:EiffelVision2]]
	[[Category:Macintosh]]		[[Category:Macintosh]]
	== Object creation ==		== Object creation ==

← Older revision		Revision as of 19:29, 31 October 2006
Line 1:		Line 1:
		+	[[Category:Macintosh]]
	== Object creation ==		== Object creation ==
	The way classes will be created is somewhat special in Eiffel Vision. Take a look at EV_ANY (, EV_ANY_I)		The way classes will be created is somewhat special in Eiffel Vision. Take a look at EV_ANY (, EV_ANY_I)

← Older revision		Revision as of 13:28, 3 September 2006
Line 70:		Line 70:
	-> The on_callback function is getting really ugly, here is my idea what we could do about that:		-> The on_callback function is getting really ugly, here is my idea what we could do about that:
	we could create a on_callback* function in the WIDGET_IMP class and then only do the selection (which event type goes to which widget?) in the on_callback function of APPLICATION_IMP. The specifics could then be done in the widget's function.		we could create a on_callback* function in the WIDGET_IMP class and then only do the selection (which event type goes to which widget?) in the on_callback function of APPLICATION_IMP. The specifics could then be done in the widget's function.
		+
		+	== EV_CARBON_DATABROWSER ==
		+	This class is an abstraction for Carbon's powerful DataBrowser [http://developer.apple.com/documentation/Carbon/Reference/databrow_reference/index.html] which is used by Vision controls like EV_TREE, EV_LIST and EV_MULTI_COLUMN_LIST.
		+
		+	This is only an experimental idea so far, but it seems to work out quite okay. So the idea I currently have is the following: It would be nice to have a heavily platform specific class which supports all the neat OS X features and interacts directly with the wrapper. The Vision conrols could then transparently use that other widget. Now, if an experienced user (a Mac user :)) wants to write something OS X specific, he could also use that class directly.