On Feb 9, 2012, at 12:09 PM, karl ramberg wrote:
On Thu, Feb 9, 2012 at 8:34 PM, Ricardo Moran richi.moran@gmail.com 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 karlramberg@gmail.com 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 richi.moran@gmail.com wrote:
On Thu, Feb 9, 2012 at 2:10 PM, Steve Thomas sthomas1@gosargon.com 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 richi.moran@gmail.com 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 richi.moran@gmail.com 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 karlramberg@gmail.com wrote:
On Tue, Feb 7, 2012 at 5:31 PM, Steve Thomas sthomas1@gosargon.com wrote: On Mon, Feb 6, 2012 at 7:49 PM, Scott Wallace scott.wallace@squeakland.org 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