[etoys-dev] New vocabularies

[karl ramberg]

On Wed, Mar 7, 2012 at 10:32 AM, Scott Wallace <scott.wallace at squeakland.org
> wrote:

> On Mar 6, 2012, at 6:56 AM, Bert Freudenberg wrote:
>
> > I noticed we have many more vocabularies now (see
> initializeStandardVocabularies). Some where added for this release, some in
> previous ones.
> >
> > However, are we sure they are correctly integrated? When I browse
> references to the old list types, e.g. TrailStyle, I see they are listed in
> at least two more places, namely:
> >
> >       ScriptEditorMorphBuilder>>literal:
> >       SymbolListType>>representsAType
> >
> > The latter seems to govern the inclusion of a list type in the type menu
> of a new variable. So shouldn't all new types be listed there? But why are
> some of the older ones left out, too? And what is the #literal: method
> about?
> >
> > Maybe there should be a single place listing valid user types?
>
> Yes, and let's do it now :)
>
> But what are the types we should offer for user-defined variables?
>
> Right now we offer around fifteen types.  The list, I think, is
> unnecessarily intimidating, around half of the items surely making most
> users nervous with their unfamiliarity.  The list of choices in the pop-up
> includes a few familiar and important ones of widespread applicability,
> such as Color, Number, Boolean, Sound, and ScriptName -- interspersed among
> many mostly unfamiliar names such as ButtonPhase, CustomEvents,
> ImageResolution, TrailStyle and WebCamResolution.
>
> The less common types are typically associated with a parameter of one or
> two commands and/or variables that occur only in a single kind of morph.
>  Thus, for example, WebCamResoution is a type that only occurs in a
> system-defined variable for WebCamMorph objects. and PatchDisplahyMode is
> only used by KedamaPatchMorphs, etc.
>
> But I suggest that making the narrow-use types available as types for
> user-defined variables is doing more harm than good, and  I wonder whether
> it would be better to offer *only* the more-or-less "universal" types.
>
> These might be only:  Boolean, Color, Graphic, Number, Player, ScriptName,
> Sound, and String -- just those eight.
>
> In practical terms, what would we be losing if we did not offer the
> "narrow-use types" for user-defined variables?  I wonder whether anyone
> here knows of any example of use of any type other than the above eight for
> a user-defined variable.  I believe that in practice the only appearance of
> the narrow-use-typed variables in scripting has been through use of
> assignment statements and "watchers" of system-defined variables of the
> particular kind of object to which they apply.
>
> What we would be gaining by whittling the list of types offered down to
> something like those eight should be self-evident:  a tractable list which
> almost every user could expect to be able to intuit the meaning of.
>
> BTW Some of the enumerated types have long been intentionally omitted from
> the type choices offered for user-defined variables, because there has
> always been a concern about too long a list, and because the types did not
> apply to any of the kinds of objects that an etoy user would be using, at
> least not in any practical way.  For example, there are a number of
> enumerated types that are only found in viewer items for AlignmentMorphs,
> to govern some table-layout properties, such ListCentering, ListDirection,
> CellPositioning, CellSpacing.  Luckily, those have never been offered as
> types for user-defined variables, and now I'm suggesting that we likewise
> leave out all the other minor types.
>
> Reactions, please!
>

I agree we should limit the types.
Your list seems good.


>
> As to the #literal: method… I'd not seen that before…
>
>
> > Secondly, we used to avoid camel-casing the items in these list types.
> However, the new AttachmentEdge type uses e.g. 'topLeft' whereas the old
> CellPositioning type uses 'top left'. Can we correct this before the new
> release?
>
> Okay, will do -- sorry I missed that.  In fact the value names get
> un-camel-cased in the Viewer even if they're declared with camel-case  But
> the camel-case versions show up in labeled watchers, so it's better to get
> this changed as you suggest.
>
>
> > Also, there is a typo, 'bottomRight center' should be 'bottomRight'
> 'center'.
>

I have fixed this.

Karl

>
> Right.
>
>
> Thank you, Bert!
>
>  -- Scott
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20120307/bb4ddffe/attachment-0001.html>