Re: [Adobe-source-devel] edit_text, unit_edit_text compound widget implementation

[Sean P. <sea...@ma...>]

We've started some clean-up that will go into .15 (should get posted =20
tomorrow).

On Apr 9, 2006, at 11:38 PM, Ralph Thomas wrote:

> I was looking over the ui-core code, and wondered if it would be
> possible to do some simplification:
>
>  1. Remove the label from edit_text_t (and maybe from popup_t as it's
> not built in on most platforms).

Even though it isn't built in on most platforms we should use it =20
where it is. One issue here is the interface required for a label on =20
one of these controls is a little different then that of a static =20
text item - they can be clicked on (selecting the text in the edit =20
text field) and they can be disabled (dimmed) - both attributes of a =20
controller, which a strict static text is not. Although the =20
implementation of the two can be shared, it shouldn't factored out =20
into any kind of common code, the label for an edit_text item need =20
not even be text to the left, it could be centered under the edit =20
text for a form as one example - these implementation details =20
shouldn't propagate into the client_assember code.

>  2. Have client_assembler create a row and put a static_text_t and an
> edit_text_t in it when it encounters an edit_text declaration with a
> non-empty name (make Eve do the layout).

Eve won't quite do what you want here for layout - a leaf node behave =20=

a  bit different then a container with respect to guides (though we =20
could change that by adding a separate property to make containers =20
behave like leaf nodes.

>  3. Remove unit_edit_text_t from ui-core.

There should be a edit_number in UI core - not a unit_edit_text which =20=

is a weird mix of items.

>  4. Implement it using a row, static_text_t, edit_text_t and popup_t
> with Eve doing the layout.

I'm pretty strongly against going this direction (and keep pushing on =20=

Foster an Mat to fix the current code to remove such factoring), the =20
fact that the implementation is using a popup for units is an =20
implementation detail for how unit selection is implemented. Also, =20
the popup and edit text portions of the edit number control have =20
behaviors keyed off of focus which is generally an attribute that =20
shouldn't be available in a simple controller. This kind of reducing =20
things to a set of primitives leads to a fairly inflexible system. A =20
controller/view pair (which is what a widget is) should be written to =20=

the semantics of a particular data type that the controller/view pair =20=

manipulates. This allow you to come up with a better widget for that =20
data type in the future without having to rework every place where it =20=

is used. For editing numbers, I would like our widget to support a =20
slider which appears when you scrub the label (Photoshop allows for =20
this kind of scrub behavior though no slider is visible), I'd also =20
like to support having a calculator appear if you type an expression =20
(as well as supporting general expressing for editing numbers) - =20
written correctly, such additions should only effect the =20
implementation of a single widget type.

>
> These are only small implications, and I don't know how they would
> change the right-to-left stratergy (as I don't know what a
> unit_edit_text_t should look like in right-to-left mode).
>
> Thanks!
>  Ralph
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642=

> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel