Layout Terminology - Revision history

SeanParent: /* Examples in CEL */

2012-09-13T00:28:35Z

‎Examples in CEL

SeanParent: /* frame */

2012-09-12T22:25:06Z

‎frame

SeanParent: /* Additional Attributes */

2011-02-02T00:25:28Z

‎Additional Attributes

SeanParent: /* Subordinate Groups */

2009-01-13T21:44:29Z

‎Subordinate Groups

SeanParent at 21:43, 13 January 2009

2009-01-13T21:43:49Z

SeanParent: /* predefined constants */

2008-12-10T17:10:34Z

‎predefined constants

SeanParent: /* predefined constants */

2008-12-10T17:10:19Z

‎predefined constants

SeanParent: Widget Set Layout Documentation moved to Layout Terminology

2008-12-10T17:00:47Z

Widget Set Layout Documentation moved to Layout Terminology

SeanParent: /* Additional Attributes */

2008-10-31T19:59:13Z

‎Additional Attributes

SeanParent: /* popup */

2008-10-31T19:58:57Z

‎popup

@@ Line 828: / Line 828: @@
 <pre>
-static_text(name: "Unfortunately, something drastic has happened. If you would like we can try to
+label(name: "Unfortunately, something drastic has happened. If you would like we can try to
              continue with the operation, but there is a chance you will blow up your computer. Would
              you like to try?", characters: 25);

@@ Line 318: / Line 318: @@
 : type: [[#array|array]]
 : default: [ 0, 0, 0, 0 ]
 ==== inset ====

@@ Line 1,162: / Line 1,162: @@
 : default: [[#empty|empty]]
 : When the value of the cell to which this widget is bound changes to this value, the reveal widget is 'turned down' or 'on'.
 ===== Examples in CEL =====

@@ Line 27: / Line 27: @@
 My proposed solution is that we allow checkbox, radio_button and popup to be used as containers:
-<code>
+<pre>
 checkbox(name: "Use File Size:") {
      edit_number();
+}
-</code>
+</pre>
 (The proper enabled/disabled behavior would still fall out of the property model - this just allows for a visual clustering). A smart implementation may choose to display such a group that only contains a single element as a row instead of a group box.

← Older revision		Revision as of 21:43, 13 January 2009
Line 1:		Line 1:
−	This is the layout behavior specifications for the default set of ASL widgets. ~~This documentation does ''~~not'' cover the attributes related to ~~the~~ binding of a widget to a ~~property model (bind~~, ~~bind_out~~, ~~etc~~.). ~~This document only deals~~ with the ~~layout behavior of~~ a widget, ~~not its semantics as they pertain~~ to a ~~model~~/~~view~~/~~controller system~~. The ~~document will~~, ~~however~~, ~~describe some attributes~~ that, ~~while not necessary for layout~~, are ~~necessary to construct~~ the ~~widget~~ (e.g., ~~optional_panel's~~ <code>~~value~~</code>)	+	This is the layout behavior specifications for the default set of ASL widgets.
		+
		+	[Originally this document did not cover the attributes related to binding and the property model nor the semantics of the widget, but those are being added in.]
		+
		+	== Discussion ==
		+
		+	=== Links vs. Buttons ===
		+
		+	[1/13/09 - sparent <at> adobe <dot> com]
		+	The current description of a <code>link</code> in this document refers to the "chain link" indicator in the Ps Image Size dialog. The term <code>link</code> however has come to be used more commonly to refer to a hyper text link. I propose we change that name and add a hyper text link widget. From here forward in the discussion when I refer to a <code>link</code> I mean a hyper text link.
		+
		+	A <code>link</code> widget is similar in nature to a button except the semantics of the action are constrained to "go to location" where a location could be a dialog, sheet, document page, panel, anchor within a document page, or other 'visual' location. Traditionally in dialogs a button with an ellipses, i.e. (Auto...), implied a link to a dialog (later extended to a sheet). The ellipses also implied "more information needed" - however that distinction is not being consistently applied. The ellipses is also used in menu items with the same implication. A link widget should take a URI as an argument and we should settle on a standard URI format to link to application UI constructs (mostly dialogs).
		+
		+	I would like to see our UI designers weigh in with a rule set for when to use a <code>link</code> vs. a button with an ellipsis so we can gain some consistency (perhaps we could simply drop this use case for buttons). If the distinction cannot be made programmatically, then I propose we have an attribute on the <code>link</code> widget gives the button/ellipse appearance without the need to embed the ellipse in the string (giving greater flexibility to the UI designers in the future).
		+
		+	As we are building more of our own UI, some thought might be given to using a link representation in menus as well.
		+
		+	A good <code>display_text</code> widget would allow for embedded links (possibly using an xhtml representation for the display text).
		+
		+	=== Subordinate Groups ===
		+
		+	[1/13/09 - sparent <at> adobe <dot> com]
		+	A recent question arose regarding adding the ability to add <em>any</em> widget into the header of a <code>group</code> widget. There are cases within our UI where we have a checkbox and a popup and the idea was to generalize this to any widget. However, upon reflection the implied semantics of a widget in the header of a group are that the items within the group are subordinates to the item in the header. The only widgets for which I can envision such a subordinate relationship are those that select from a fixed set of values, specifically, checkbox, radio_button, and popup.
		+
		+	For a checkbox, the implication is that the subordinate items only apply when the checkbox is in it's positive state (and would be disabled otherwise). For a radio_button, the implication is that the subordinate items only apply when the state associated with the radio button is selected. For a popup, the implication is that there are multiple panels of subordinate items and the items on non-visible panels will be disabled (with the items on the current panel being enabled for the current popup selection). This distinguishes the popup group case from the tab panel case where there is no implication that the tabs are making any "choice" other than selecting which view to display.
		+
		+	My proposed solution is that we allow checkbox, radio_button and popup to be used as containers:
		+
		+	<code>
		+	checkbox(name: "Use File Size:") {
		+	edit_number();
		+	}
		+	</code>
		+
		+	(The proper enabled/disabled behavior would still fall out of the property model - this just allows for a visual clustering). A smart implementation may choose to display such a group that only contains a single element as a row instead of a group box.

	== CEL Primer ==		== CEL Primer ==

@@ Line 46: / Line 46: @@
 : The type system for CEL is open. Values are stored in an adobe::any_regular_t which can hold any regular type. Client functions can be introduced that return values of types other than those listed and other functions may process those value.
-=== predefined constants ===
+=== Predefined Constants ===
 : There are a number of predefined constants in the layout library - unless otherwise specified the value of the constant is not defined:
 * align_left

@@ Line 54: / Line 54: @@
 * place_column
 * place_overview
 == Associated Structures ==

@@ Line 883: / Line 883: @@
 : type: [[#name|name]] or [[#array|array]] of [[#dictionary|dictionaries]]
 : default: [ ]
-: Describes the items to be listed in the popup. If a [[#name|name]] is specified then the popup items are bound to an output of the data model. The value bound to should contain an [[#array|array]] of [[#dictionary|dictionaries]] as described here. [Note: binding items is currently not implemented in the APL widget set.] Each [#dictionary|dictionary]] in the [[#array|array]] has the following keys:
+: Describes the items to be listed in the popup. If a [[#name|name]] is specified then the popup items are bound to an output of the data model. The value bound to should contain an [[#array|array]] of [[#dictionary|dictionaries]] as described here. [Note: binding items is currently not implemented in the APL widget set.] Each [[#dictionary|dictionary]] in the [[#array|array]] has the following keys:
 :; name