Hi Marko.
Thank you for your feedback.
> Also moving towards a system without files (and therefore no textual JS
> representation of scripts), this feels wrong to me.
I am not sure what you mean by "no textual representations" - how will editing
the scripts of an object will look like when there's no textual representation
of scripts? What is a JS representation? And will it still be possible with
your CodeDB plan to develop a part locally with our editor in a world and to
publish it after a number of coherent changes?
> So in my opinion it really only adds clutter to what you really want to
> see/do.
> PS: I also have to add that I never really saw the need for method categories
> and the only systems/languages (I know) that do have this are Lively and
> Squeak... :-/
The rationale here is: There are no private methods in ST or JS, but certain
objects are implemented using lots of methods (which is good!), but not all
should be meant to be used as interface by users of such objects - tagging
those as, for example, "private" and the intended interface as "public" might
alleviate finding the correct method for a certain task.
I personally find my self searching for the correct method in Lively often, do
like tagged scripts especially when there are "framework parts"/"template
parts" that users should adapt slightly to their needs (we had those in a
recent demo app), and do appreciate the categories in Smalltalk systems like
Squeak :-)
But I do understand that any implementation and any UI of a feature will feel
like clutter if you don't want that feature.
> So an additional one-line text morph for "tagging" would be a simple and nice
> solution.
Currently, the editor can also display all scripts at once, which, for example,
allows to search in all scripts of an object (and only these) - very important
for refactorings as long as there are no sophisticated refactoring tools.
Further, the editor also displays connections (Lively's data binding). In these
two situations a text field for tagging a single script wouldn't make sense.
An alternative is to use multiple panes as the SCB uses, probably with drag and
drop - however, we decided to keep the editor lightweight and stay with it's
three-pane layout.
I do however see your point in regards to exposing implementation details with
addScript - but like that the editor does not hide these details, because this
way the scripts are added as it's possible everywhere in the system - feels
unified and direct to me.
Best,
Lauritz
On Nov 28, 2011, at 2:13 PM, Roeder, Marko wrote:
> Hi Lauritz -
>
> I am a bit indecisive when it comes to adding UI elements vs. having more
> code in the code pane. So here are my thoughts on that:
>
> On the one hand you could argue that keeping the UI of the script editor
> clean and easy is a good idea looking at how browser (e.g. the SCB) do look
> like. But I think that you should also hide as many "implementation details"
> of how scripts are added and categorized/tagged, meaning that even
> this.addScript(...) (and therefore .categorize(...) too) is some kind of
> information a beginner/user should not need to see. So an additional one-line
> text morph for "tagging" would be a simple and nice solution.
> On the other hand even the "implementation details" might be interesting for
> people who e.g. want to add scripts programmatically (you could argue) but
> this is not majority of users. So in my opinion it really only adds clutter
> to what you really want to see/do.
> Also moving towards a system without files (and therefore no textual JS
> representation of scripts), this feels wrong to me.
>
> So what do you think? Comments, thoughts? ;-)
>
> Best,
>
> - Marko
>
>
> PS: I also have to add that I never really saw the need for method categories
> and the only systems/languages (I know) that do have this are Lively and
> Squeak... :-/
>
>
> On Nov 28, 2011, at 20:51 , Lauritz Thamsen wrote:
>
>> Hi.
>>
>> We added script tagging to our Object Editor (Script Editor).
>>
>> A script might be in several categories at the same time, so we allow
>> multiple tags. Further, we don't want the editor to have as many UI elements
>> as our System Code Browser. Therefore, we tag scripts like they are added.
>> Programmatically in the editor's script pane:
>>
>> this.addScript(function example() {
>> alertOK('hello');
>> }).categorize(['example', 'public']);
>>
>> Any feedback or comments? :-)
>>
>> Best,
>> Lauritz
>> _______________________________________________
>> lively-kernel mailing list
>> [email protected]
>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>
> _______________________________________________
> lively-kernel mailing list
> [email protected]
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
_______________________________________________
lively-kernel mailing list
[email protected]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
