Smalltalk › Frameworks & Tools › eToys Development

Etoys: Etoys-Richo.103.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

32 messages Options

commits-2

Etoys: Etoys-Richo.103.mcz

Ricardo Moran uploaded a new version of Etoys to project Etoys:
http://source.squeak.org/etoys/Etoys-Richo.103.mcz

==================== Summary ====================

Name: Etoys-Richo.103
Author: Richo
Time: 6 February 2012, 5:16:57 pm
UUID: 84503c98-7c83-064f-957f-5bacf093d22e
Ancestors: Etoys-kfr.102

Sixteen items for Squeakland 2012:

11. On Add Variable: Show options for value type - to make it easier to discover different types besides number (Ex: player, color, etc).

=============== Diff against Etoys-kfr.102 ===============

Item was changed:
----- Method: Player>>addInstanceVariable (in category 'slots-user') -----
addInstanceVariable
"Offer the user the opportunity to add an instance variable, and if he goes through with it, actually add it."

| itsName initialValue typeChosen usedNames initialAnswer setterSelector originalString |
+ usedNames := self class instVarNames.
- usedNames _ self class instVarNames.

+ initialAnswer := Utilities keyLike: ('var' translated, (usedNames size + 1) asString) satisfying: [:aKey | (usedNames includes: aKey) not].
- initialAnswer _ Utilities keyLike: ('var' translated, (usedNames size + 1) asString) satisfying: [:aKey | (usedNames includes: aKey) not].

+ originalString := FillInTheBlank request: 'name for new variable: ' translated initialAnswer: initialAnswer.
- originalString _ FillInTheBlank request: 'name for new variable: ' translated initialAnswer: initialAnswer.
Cursor wait showWhile: [
originalString isEmptyOrNil ifTrue: [^ self].
+ itsName := ScriptingSystem acceptableSlotNameFrom: originalString forSlotCurrentlyNamed: nil asSlotNameIn: self world: self costume world.
- itsName _ ScriptingSystem acceptableSlotNameFrom: originalString forSlotCurrentlyNamed: nil asSlotNameIn: self world: self costume world.

itsName size == 0 ifTrue: [^ self].
self assureUniClass.
+ typeChosen := self askUserForNewTypeFor: itsName.
- typeChosen _ self initialTypeForSlotNamed: itsName.
self slotInfo at: itsName put: (SlotInformation new initialize type: typeChosen).
+ initialValue := self initialValueForSlotOfType: typeChosen.
- initialValue _ self initialValueForSlotOfType: typeChosen.
self addInstanceVarNamed: itsName withValue: initialValue.
self compileInstVarAccessorsFor: itsName.
+ setterSelector := Utilities setterSelectorFor: itsName.
- setterSelector _ Utilities setterSelectorFor: itsName.
((self class allSubInstances copyWithout: self) reject: [:e | e isSequentialStub]) do:
[:anInstance | anInstance perform: setterSelector with: initialValue].
self regenerateScripts.
+ self updateAllViewersAndForceToShow: ScriptingSystem nameForInstanceVariablesCategory.
- self updateAllViewersAndForceToShow: ScriptingSystem nameForInstanceVariablesCategory
]!

Item was added:
+ ----- Method: Player>>askUserForNewTypeFor: (in category 'slots-user') -----
+ askUserForNewTypeFor: slotName
+ | typeChoices menuCaption |
+ typeChoices := Vocabulary typeChoices asOrderedCollection.
+ [self costume renderedMorph defaultPatch]
+ on:Exception
+ do:[ typeChoices remove: #Patch ifAbsent: [typeChoices]].
+ menuCaption := 'Choose the TYPE
+ for {1}
+ ' translated, slotName, '
+ (currently {2})' translated format: {slotName. (self slotInfoAt: slotName) type translated}.
+ ^ (SelectionMenu
+ labelList: (typeChoices collect: [:t | t translated])
+ lines: #()
+ selections: typeChoices)
+ startUpWithCaption: menuCaption.!

Item was changed:
----- Method: Player>>chooseSlotTypeFor: (in category 'slots-user') -----
chooseSlotTypeFor: aGetter
"Let the user designate a type for the slot associated with the given getter"

+ | typeChosen slotName |
+ slotName := Utilities inherentSelectorForGetter: aGetter.
+ typeChosen := self askUserForNewTypeFor: slotName.
- | typeChoices typeChosen slotName |
- slotName _ Utilities inherentSelectorForGetter: aGetter.
- typeChoices _ Vocabulary typeChoices asOrderedCollection.
- [self costume renderedMorph defaultPatch] on:Exception do:[ typeChoices remove: #Patch ifAbsent: [typeChoices]].
- typeChosen _ (SelectionMenu labelList: (typeChoices collect: [:t | t translated]) lines: #() selections: typeChoices) startUpWithCaption:
- ('Choose the TYPE
- for {1}
- ' translated, slotName, '
- (currently {2})' translated format: {slotName. (self slotInfoAt: slotName) type translated}).
typeChosen isEmptyOrNil ifTrue: [^ self].
(self typeForSlot: slotName) capitalized = typeChosen ifTrue: [^ self].

(self slotInfoAt: slotName) type: typeChosen.
self class allInstancesDo: "allSubInstancesDo:"
[:anInst | anInst instVarNamed: slotName asString put:
(anInst valueOfType: typeChosen from: (anInst instVarNamed: slotName))].
self updateAllViewers. "does siblings too"
self changeTypesInWatchersOf: slotName. "does siblings too"

!

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Etoys: Etoys-Richo.103.mcz

Nice.

Karl

On Mon, Feb 6, 2012 at 9:17 PM, <[hidden email]> wrote:

> Ricardo Moran uploaded a new version of Etoys to project Etoys:
> http://source.squeak.org/etoys/Etoys-Richo.103.mcz
>
> ==================== Summary ====================
>
> Name: Etoys-Richo.103
> Author: Richo
> Time: 6 February 2012, 5:16:57 pm
> UUID: 84503c98-7c83-064f-957f-5bacf093d22e
> Ancestors: Etoys-kfr.102
>
> Sixteen items for Squeakland 2012:
>
> 11. On Add Variable: Show options for value type - to make it easier to discover different types besides number (Ex: player, color, etc).
>
> =============== Diff against Etoys-kfr.102 ===============
>
> Item was changed:
> ----- Method: Player>>addInstanceVariable (in category 'slots-user') -----
> addInstanceVariable
> "Offer the user the opportunity to add an instance variable, and if he goes through with it, actually add it."
>
> | itsName initialValue typeChosen usedNames initialAnswer setterSelector originalString |
> + usedNames := self class instVarNames.
> - usedNames _ self class instVarNames.
>
> + initialAnswer := Utilities keyLike: ('var' translated, (usedNames size + 1) asString) satisfying: [:aKey | (usedNames includes: aKey) not].
> - initialAnswer _ Utilities keyLike: ('var' translated, (usedNames size + 1) asString) satisfying: [:aKey | (usedNames includes: aKey) not].
>
> + originalString := FillInTheBlank request: 'name for new variable: ' translated initialAnswer: initialAnswer.
> - originalString _ FillInTheBlank request: 'name for new variable: ' translated initialAnswer: initialAnswer.
> Cursor wait showWhile: [
> originalString isEmptyOrNil ifTrue: [^ self].
> + itsName := ScriptingSystem acceptableSlotNameFrom: originalString forSlotCurrentlyNamed: nil asSlotNameIn: self world: self costume world.
> - itsName _ ScriptingSystem acceptableSlotNameFrom: originalString forSlotCurrentlyNamed: nil asSlotNameIn: self world: self costume world.
>
> itsName size == 0 ifTrue: [^ self].
> self assureUniClass.
> + typeChosen := self askUserForNewTypeFor: itsName.
> - typeChosen _ self initialTypeForSlotNamed: itsName.
> self slotInfo at: itsName put: (SlotInformation new initialize type: typeChosen).
> + initialValue := self initialValueForSlotOfType: typeChosen.
> - initialValue _ self initialValueForSlotOfType: typeChosen.
> self addInstanceVarNamed: itsName withValue: initialValue.
> self compileInstVarAccessorsFor: itsName.
> + setterSelector := Utilities setterSelectorFor: itsName.
> - setterSelector _ Utilities setterSelectorFor: itsName.
> ((self class allSubInstances copyWithout: self) reject: [:e | e isSequentialStub]) do:
> [:anInstance | anInstance perform: setterSelector with: initialValue].
> self regenerateScripts.
> + self updateAllViewersAndForceToShow: ScriptingSystem nameForInstanceVariablesCategory.
> - self updateAllViewersAndForceToShow: ScriptingSystem nameForInstanceVariablesCategory
> ]!
>
> Item was added:
> + ----- Method: Player>>askUserForNewTypeFor: (in category 'slots-user') -----
> + askUserForNewTypeFor: slotName
> + | typeChoices menuCaption |
> + typeChoices := Vocabulary typeChoices asOrderedCollection.
> + [self costume renderedMorph defaultPatch]
> + on:Exception
> + do:[ typeChoices remove: #Patch ifAbsent: [typeChoices]].
> + menuCaption := 'Choose the TYPE
> + for {1}
> + ' translated, slotName, '
> + (currently {2})' translated format: {slotName. (self slotInfoAt: slotName) type translated}.
> + ^ (SelectionMenu
> + labelList: (typeChoices collect: [:t | t translated])
> + lines: #()
> + selections: typeChoices)
> + startUpWithCaption: menuCaption.!
>
> Item was changed:
> ----- Method: Player>>chooseSlotTypeFor: (in category 'slots-user') -----
> chooseSlotTypeFor: aGetter
> "Let the user designate a type for the slot associated with the given getter"
>
> + | typeChosen slotName |
> + slotName := Utilities inherentSelectorForGetter: aGetter.
> + typeChosen := self askUserForNewTypeFor: slotName.
> - | typeChoices typeChosen slotName |
> - slotName _ Utilities inherentSelectorForGetter: aGetter.
> - typeChoices _ Vocabulary typeChoices asOrderedCollection.
> - [self costume renderedMorph defaultPatch] on:Exception do:[ typeChoices remove: #Patch ifAbsent: [typeChoices]].
> - typeChosen _ (SelectionMenu labelList: (typeChoices collect: [:t | t translated]) lines: #() selections: typeChoices) startUpWithCaption:
> - ('Choose the TYPE
> - for {1}
> - ' translated, slotName, '
> - (currently {2})' translated format: {slotName. (self slotInfoAt: slotName) type translated}).
> typeChosen isEmptyOrNil ifTrue: [^ self].
> (self typeForSlot: slotName) capitalized = typeChosen ifTrue: [^ self].
>
> (self slotInfoAt: slotName) type: typeChosen.
> self class allInstancesDo: "allSubInstancesDo:"
> [:anInst | anInst instVarNamed: slotName asString put:
> (anInst valueOfType: typeChosen from: (anInst instVarNamed: slotName))].
> self updateAllViewers. "does siblings too"
> self changeTypesInWatchersOf: slotName. "does siblings too"
>
> !
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Scott Wallace

Re: Etoys: Etoys-Richo.103.mcz

In reply to this post by commits-2

>From the perspective of "minimizing user paralysis", I think there's an argument to be made against this change, and indeed perhaps even an argument to be made to go in the opposite direction: instead of forcing the user to make *two* modal decisions right away (first dream up a variable name, then decide on a value-type) it might be preferable to have the user make *no* modal decisions when adding a variable.

This has long been a good choice for scripts -- we give you a default name, such as "script3", and you can leave it that way if you want or you can, at your leisure, edit the name into something useful and descriptive. But you're not blocked by being forced to give your attention to specifying a name right away.

Thinking up a name can be a powerful blocker; choosing a type from list that one does not understand might be worse. Having both of these standing in the way of creating a user-defined variable might not be a good thing.

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Just tossing this out for discussion...

-- Scott

On Feb 6, 2012, at 8:17 PM, [hidden email] wrote:

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Scott Wallace

Re: Etoys: Etoys-Richo.103.mcz

In reply to this post by commits-2

One bug I quickly ran into with this is that if you add a variable but then instead of choosing a type from the pop-up-list, you just click somewhere else, you fall into a debugger.

-- Scott

On Feb 6, 2012, at 8:17 PM, [hidden email] wrote:

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Etoys: Etoys-Richo.103.mcz

In reply to this post by Scott Wallace

On Tue, Feb 7, 2012 at 1:49 AM, Scott Wallace
<[hidden email]> wrote:

> >From the perspective of "minimizing user paralysis", I think there's an argument to be made against this change, and indeed perhaps even an argument to be made to go in the opposite direction: instead of forcing the user to make *two* modal decisions right away (first dream up a variable name, then decide on a value-type) it might be preferable to have the user make *no* modal decisions when adding a variable.
>
> This has long been a good choice for scripts -- we give you a default name, such as "script3", and you can leave it that way if you want or you can, at your leisure, edit the name into something useful and descriptive. But you're not blocked by being forced to give your attention to specifying a name right away.
>
> Thinking up a name can be a powerful blocker; choosing a type from list that one does not understand might be worse. Having both of these standing in the way of creating a user-defined variable might not be a good thing.
>
> Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.
>
> We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.
>
> This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…
>
> Just tossing this out for discussion...

Is this code for a other system or can it be filed into Etoys ?

Another way of doing this would be to make a Hypercard like Variable Info dialog
http://www.loper-os.org/wp-content/hypercard-calc/hc11.jpg

A modal window with all the menu options presented for a variable: a
menu to change the variable type, a field change the name etc.

Karl

>
> -- Scott
>
>
> On Feb 6, 2012, at 8:17 PM, [hidden email] wrote:
>
>> Ricardo Moran uploaded a new version of Etoys to project Etoys:
>> http://source.squeak.org/etoys/Etoys-Richo.103.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Etoys-Richo.103
>> Author: Richo
>> Time: 6 February 2012, 5:16:57 pm
>> UUID: 84503c98-7c83-064f-957f-5bacf093d22e
>> Ancestors: Etoys-kfr.102
>>
>> Sixteen items for Squeakland 2012:
>>
>> 11. On Add Variable: Show options for value type - to make it easier to discover different types besides number (Ex: player, color, etc).
>> _______________________________________________
>> etoys-dev mailing list
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Steve Thomas

Re: Etoys: Etoys-Richo.103.mcz

In reply to this post by Scott Wallace

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Etoys: Etoys-Richo.103.mcz

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'

Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: Etoys-Richo.103.mcz

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,

Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: Etoys-Richo.103.mcz

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

NewVariable.2.cs (9K) Download Attachment

Steve Thomas

Re: Etoys: Etoys-Richo.103.mcz

Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: Etoys-Richo.103.mcz

On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas <[hidden email]> wrote:

Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Great idea, how about now?

Cheers,

Richo

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

NewVariable.3.cs (10K) Download Attachment

Karl Ramberg

Re: Etoys: Etoys-Richo.103.mcz

This looks nice :-)

Great job Ricardo

Karl

On Thu, Feb 9, 2012 at 7:53 PM, Ricardo Moran <[hidden email]> wrote:

On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas <[hidden email]> wrote:

Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Great idea, how about now?

Cheers,
Richo

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Etoys: Etoys-Richo.103.mcz

In reply to this post by Ricardo Moran

On Thu, Feb 9, 2012 at 7:53 PM, Ricardo Moran <[hidden email]> wrote:

On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas <[hidden email]> wrote:
Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Great idea, how about now?

Cheers,
Richo

I think this is a good solution for making the variable types visible and not buried into a menu.

It has a default selected and still give hints to explore further.

You can choose to name the variable or just use the default name.

Karl

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Etoys: Etoys-Richo.103.mcz

In reply to this post by Ricardo Moran

We should hook this up to the Viewer variable menu in

Player slotInfoButtonHitFor:inViewer:

'rename' and 'change value type' could be replaced by this panel.( I'm not sure what to call it: Variable info ?)

I think it's good for consistency that we present just one panel to rename and choose variable type.

Karl

On Thu, Feb 9, 2012 at 7:53 PM, Ricardo Moran <[hidden email]> wrote:

On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas <[hidden email]> wrote:

Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Great idea, how about now?

Cheers,
Richo

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: Etoys-Richo.103.mcz

Yes, you're right. And we should add the "decimal places" if the selected type is number as well.

On Thu, Feb 9, 2012 at 4:24 PM, karl ramberg <[hidden email]> wrote:

We should hook this up to the Viewer variable menu in
Player slotInfoButtonHitFor:inViewer:

'rename' and 'change value type' could be replaced by this panel.( I'm not sure what to call it: Variable info ?)

I think it's good for consistency that we present just one panel to rename and choose variable type.

Karl

On Thu, Feb 9, 2012 at 7:53 PM, Ricardo Moran <[hidden email]> wrote:

On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas <[hidden email]> wrote:

Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Great idea, how about now?

Cheers,
Richo

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Karl Ramberg

Re: Etoys: Etoys-Richo.103.mcz

On Thu, Feb 9, 2012 at 8:34 PM, Ricardo Moran <[hidden email]> wrote:

, you're right. And we should add the "decimal places" if the selected type is number as well.

Yes

Number and Point have 'decimal places...'

Player have 'tiles to get...' ( I'm not really familiar with this)

Karl

On Thu, Feb 9, 2012 at 4:24 PM, karl ramberg <[hidden email]> wrote:

We should hook this up to the Viewer variable menu in
Player slotInfoButtonHitFor:inViewer:

'rename' and 'change value type' could be replaced by this panel.( I'm not sure what to call it: Variable info ?)

I think it's good for consistency that we present just one panel to rename and choose variable type.

Karl

On Thu, Feb 9, 2012 at 7:53 PM, Ricardo Moran <[hidden email]> wrote:

On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas <[hidden email]> wrote:

Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Great idea, how about now?

Cheers,
Richo

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made the following dialog using the PropertiesMorph as suggested.

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:

This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:

On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:

Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.

Agreed. Something like:

or

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.

And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…

Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Scott Wallace

Re: Etoys: Etoys-Richo.103.mcz

On Feb 9, 2012, at 12:09 PM, karl ramberg wrote:

On Thu, Feb 9, 2012 at 8:34 PM, Ricardo Moran <[hidden email]> wrote:
, you're right. And we should add the "decimal places" if the selected type is number as well.

Yes

Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

Karl

On Thu, Feb 9, 2012 at 4:24 PM, karl ramberg <[hidden email]> wrote:
We should hook this up to the Viewer variable menu in
Player slotInfoButtonHitFor:inViewer:

'rename' and 'change value type' could be replaced by this panel.( I'm not sure what to call it: Variable info ?)

Ysy!

* The wording in the menu for the item that would bring up the panel could be "variable name and type" perhaps. Or just "name & type".

* When the panel is brought up for an already-existing variable, it should not show the wording "new variable". Maybe the title is superfluous even in the new-variable case?

* Expecting the panel completely to replace the pop-up menu is perhaps going too far at this time...

For one thing, there are items "simple watcher" and "detailed watcher" wanted for all variables, whether user-defined or built-in, and "remove variable" for user-defined variables, plus type-specific commands (as opposed to properties) desired for some variables, such as the "tiles to get…" for Player-valued variables.

And "types" can have have extra, type-specific, state, as Richo points out -- e.g. "decimal places" for Number-valued and Point-valued variables but *not* for any other types. Thus, what's in the panel, and indeed perhaps even the physical size and layout of the panel, might need to change each time a different value-type is selected in the panel.

Doing all this via a panel is not unthinkable but, but would certainly involve more work than just having the name and type be in the panel for now. Or perhaps the decimal-places item can be there, and can come or go depending on what the currently-chosen type is...

* If the panel does *not* completely replace the pop-up menu, then it seems we have two choices:

(a) have the name-and-type panel invoked by a "name & type" item in the pop-up menu, which replaces both "rename" and "change value type"

(b) in the viewer line, only for user-defined variables, add a separate little button, which you click on to get the name/type panel presented. In our vpri prototype, we used a small, downward-facing black triangle situated to the right of the variable name for a comparable feature.

* One last thing. As we all know, the user can provide a "balloon help" message for a user-defined script. I think we should provide such a feature also for user-defined variables. In fact, an earlier version of etoys did have such a feature, and there is even a place in the "SlotInformation" object that defines a user-defined variable, called "documentation", to store this balloon help. We would just need to add a UI for editing it (in the slot-information menu in the viewer) and then to make sure the user-specified balloon-help is used when construct items for the Viewer (in Player >> methodInterfacesForInstanceVariablesCategoryIn:). A nice little displacement-activity project for someone out there…. any takers?

This is all going in a great direction!

-- Scott

I think it's good for consistency that we present just one panel to rename and choose variable type.

Karl

On Thu, Feb 9, 2012 at 7:53 PM, Ricardo Moran <[hidden email]> wrote:

On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas <[hidden email]> wrote:
Nice, May want to add arrows to Type (similar to the way make sound scripting tile works) to invite kids to click on it).

Great idea, how about now?

Cheers,
Richo

Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Stephen

On Thu, Feb 9, 2012 at 12:01 PM, Ricardo Moran <[hidden email]> wrote:
Hi,

I've made the following dialog using the PropertiesMorph as suggested.

<NewVariableDialog.png>

It opens by default when clicking on the "add new variable" button. I think this solution is better than the two modal dialogs and it also makes the different slot types a little more visible.

I attached a change set if you want to test it.

Cheers,
Richo

On Wed, Feb 8, 2012 at 12:21 PM, Ricardo Moran <[hidden email]> wrote:
This would be easy to do and it would be a great improvement, but I don't think this dialog should be open by request. If I understood correctly, the problem that originated this issue was that the slot types other than #Number were difficult to find, so hiding this dialog won't solve it.

Cheers,
Richo

On Tue, Feb 7, 2012 at 3:07 PM, karl ramberg <[hidden email]> wrote:

On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas <[hidden email]> wrote:
On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace <[hidden email]> wrote:
Better, arguably, is to give a newly-launched variable a default name and a default value-type, and then also make it more straightforward and inviting to change the name and change the value-type, without needing to fish in menus.
Agreed. Something like:
<AddVariable I.png>

or

<AddVariable II.png>

Nice.

Maybe we should use the PropertiesMorphs for this ?

Also some of the variable types have additional spec
Number and Point have 'decimal places...'
Player have 'tiles to get...' ( I'm not really familiar with this)

After reading Scotts mail I think this dialog should be presented by request, not by default.
And that we bypass the 'FillInTheBlank' naming of variable in the first place ?

Karl

We did that a while ago in an internal vpri fork: add-variable gives you a variable with a default name and a value-type already provided; when and if desired, click on the variable name and text-edit to rename the variable; click on a little "value-type" icon to the right of the name to get a list of value-type choices. No modal roadblocks to getting started, no fishing in menus to make changes.

This improves the work-flow of add-a-variable quite a bit, and might be a good thing for squeakland as well. However, it's probably too late in the development cycle of the imminent release to make such a change…
Ideally we would have a group of kids we who could help test these ideas.

I don't see a problem with waiting at this point.

Stephen

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Scott Wallace

Re: Etoys: Etoys-Richo.103.mcz

In reply to this post by Steve Thomas

On Feb 9, 2012, at 9:10 AM, Steve Thomas wrote:

> Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Right -- and it would be very good if in the gallery or guides or *somewhere* we had examples illustrating use of every one of the types.

-- Sott
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: Etoys-Richo.103.mcz

Hi,

I've made a partial update on the new dialog (change set attached). I haven't added the type-specific "decimal places" yet, but I replaced the menu items "rename <var>" and "change value type" with the item "change variable info...".

I also fixed the code a little, removed the title, and added a couple of #translated sends.

Cheers,

Richo

On Thu, Feb 9, 2012 at 9:56 PM, Scott Wallace <[hidden email]> wrote:

On Feb 9, 2012, at 9:10 AM, Steve Thomas wrote:

> Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Right -- and it would be very good if in the gallery or guides or *somewhere* we had examples illustrating use of every one of the types.

-- Sott

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

NewVariable2.2.cs (38K) Download Attachment

Ricardo Moran

Re: Etoys: Etoys-Richo.103.mcz

Sorry, the last change set had a bug when the slot was removed while the dialog was still open. I fixed it in this new change set.

Cheers,

Richo

On Fri, Feb 10, 2012 at 6:41 PM, Ricardo Moran <[hidden email]> wrote:

Hi,

I've made a partial update on the new dialog (change set attached). I haven't added the type-specific "decimal places" yet, but I replaced the menu items "rename <var>" and "change value type" with the item "change variable info...".

I also fixed the code a little, removed the title, and added a couple of #translated sends.

Cheers,
Richo

On Thu, Feb 9, 2012 at 9:56 PM, Scott Wallace <[hidden email]> wrote:

On Feb 9, 2012, at 9:10 AM, Steve Thomas wrote:

> Ed Team should think about Quick Guides on Variables, and perhaps balloon help when you mouse over the variable types.

Right -- and it would be very good if in the gallery or guides or *somewhere* we had examples illustrating use of every one of the types.

-- Sott

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

NewVariable2.3.cs (38K) Download Attachment