Is this possible? If yes, how do I do this?

If this is the current debugger, I'd suggest the improvement that there is a way to see the full exception message as in some cases the message is actually useful.

When trying to merge archives into profiles (as done in current postLoad) I get the following exception:

Problematic code is: ViScriptArchive mergeAll.

The problem seems to be that old script code (here ViQueryTransformStep) gets merged with new ViScriptParts.

Do I somehow need to migrate old scripts to new ones?

Example: Add second column to table-like view.

Another example: Set header text in property script (meta data) for table-like view.

The input and output kind of a query step definition should influence the outcome of a merge operation. If there is a generic type and a specific type, the code for the specific type should be used. If the types are both specific, there will be no merge.

Whenever methods change, the new compiled method will not be saved into the input ist for the script. Next time, the script is evaluated, the old compiled methods appear. Kind of dangerous... :-/

A ViPane manages some queries and some views. A ViMultiPaneEditor provides interactive access to multiple panes and supports layout modifications. Then, there are query references, which represent pointers to queries and a unit of reuse (and re-labeling).

All three means together should be used to provide an abstraction mechanism for creating tools:

• A view that manages multiple ViPaneinstances similar to ViMultiPaneEditor
• That view manages queries by means of their references
• There should be one input and one output (also thinking of the tuple mechanism)
• On top, no halo should be allowed to support pane access with a single click

I changed the view property in the script and can not figure out how to trigger updating the adaption of the view. Somehow I managed to get into a situation where this is not done automatically.

After I was updating to the most recent version mt.494 (as of the creation of this issue) ViTreePlainView(ViStandardItemView)>>ensureSelection was failing because a view apparently does not understand selectFirst.

When I create a new tool and do some erroneous statement in my script an indicator in the tool will show just as in the following image:

When I fix the error the contents of the tool are updated, but the error sign is still displayed:

For beginners this can be disturbing because it is not quite clear if the error still occurs or not. Clicking the script's name in the halo again hot fixes that problem though.

Provide a real continuation when debugging failed script evaluations. At the moment, it copies only the stack and all bindings.

They should also follow their referenced scripts and adopt those, too.

Use case: Adding a tool from its temporary orga into the default one.

When I want to use a button, it is not discoverable how I use it's functionality. From other widgets I know the #text property which also works here as the button title.

Example scenario:

In ViButtonBarView's updateFor:in: method I found that there is #clicked and #enabled, but somehow I struggle to get them to work.

You cannot remove a properties by deleting its association from the editor. You have to set it to nil. Then it will disappear.

We should find a way to support that, although there are some properies not visible anyway for cluttering issues... Hmmmm....

When I instantiate a tool from the bookmarks pane, I would like to do changes to a copy instead of the thing itself. Further a separate step to save to tool (i. e. bookmark it again) would be nice to make this action explicit.

I want to save state in a script to implement a toggle button, but I don't know where to put that information.

The buttons in the image should (de)activate each other when clicked such that a toggle button would be the outcome where only one of the two buttons is enabled.

Consider the evaluation model for UNIX shell scripts. There, filters are executed in parallel (or concurrently) and there is a stream of bytes between filters (stdin/stdout). In a similar fashion, queries should be "in execution" and provide data for object buffers in between. Such buffers should be SharedQueue instances. Queries should be allowed to wait for several objects before processing them. To be more precise, this is a more generic way to describe queries without abstracting from Collection api:

"Filter process."
[:in :out :q |
     | buffer |
     buffer := OrderedCollection new.
     [in nextOrNil] whileNotNil: [:obj |
          buffer add: obj].
     "Query code"
     buffer := q value: buffer.
     buffer do: [:obj |
          out nextPut: obj].

     "or query code each"
     buffer do: [:o |
          out nextPut: (q value: o)].
].

Having access to this kind of queries, programmers may write something like this:

"New query."
[:in :out |
     [in next in: [:obj |
          out nextPut: obj asString size]] repeat].

I have the following situation:

• One script 'Item list' which is a list of items one can select
• One script 'Editor' which holds a string which can be edited by the user
• The output of the 'Item list' is the input of the 'editor'. However, the 'item list' does not influence the string edited but the output generated with this input and the string.

Where should this be implemented? Is this possible using only scripts and stock views or does this require a new View, as it changes the way data flows?

When I use the "Add Class" from the bookmark panel, I have to use ctrl+d on the snippet to get a new class. The way I'm used to it using the standard tools is that Ctrl+S creates a new class

It is not easily discoverable a) how to do projections – return an association and b) what is available as a key – e.g. #text or #icon for the projection into a widget.

There is no GUI to set the "outer" as target for input or output. Adding it manually to the meta script removes it later somehow...

Lookup id in steps organization.

I wanted to use thel label (here ZeroDivide) as Input for my own script. Everytime the debugger is spawned I wanted my tool to update its input.

I have two panels and I want to assemble them as it is shown in https://vimeo.com/116751102. However, simply moving them on to each other does not do the trick. What am I missing here?

I have a situation where I want to trigger script execution manually because I know that the underlying data has changed.
This is the case because my tool contains scripts with side effects.

I want to trigger the re-execution of a particular script after my side effected code ran.

I've tried to use the ViTextEdit to create a source code editor. First I've tried the following script:

[:in :out | ([:all | all collect: [:o |
    ([:obj | {
        [:thing | 
        #text -> (thing getString) asText
                <- [:text | self halt] ] value: obj }]
    value: o)]]
value: in) do: [:result | out add: result]]
-> {
    #isProperty -> true.
    #label -> 'TextEdit Demo'.
    #priority -> 60.
    #view -> ViTextEdit.
}

This leads to an empty ViTextEdit pane. I have then changed the code to use the object property instead. And removed the writing to #object.

[:in :out | ([:all | all collect: [:o |
    ([:obj | {
        [:thing | 
        #object -> (thing getString) asText ] value: obj }]
    value: o)]]
value: in) do: [:result | out add: result]]
...

This leads to a box were the source code is displayed and can be edited, but not saved. This kind of makes sense, as the object of a TextEdit should be a text. I then readded the writing part:

[:in :out | ([:all | all collect: [:o |
    ([:obj | {
        [:thing | 
        #object -> (thing getString) asText
                <- [:text | self halt] ] value: obj }]
    value: o)]]
value: in) do: [:result | out add: result]]
...

The output in the pane is then:

[closure] in ViScriptPart class>>convertProperty:

Either way, something seems to be broken. The current way to solve this (according to the Vivide Package Browser) is to use a ViTextView and set the script property editable to true.

There is no signal propagated from widget through pane to surrounding system window. #artifactsAdded: is handled in widget and does not bubble up to window.

The menu item is there but new-style scripts cannot be registered.

The method editor (for compiled methods) seems to be broken somehow. The code, which the debugger shows you, can be modified but only for this context. The real code is not touched...

Not only for instances or subclasses of/from TestCase.

A morph's border grows inwards. See Morph >> innerBounds, which will be used for layouting (Morph >> layoutBounds). I think we messed up this constraint, e.g., in TViOverlayMessages.

You can see 1px flickering caused by several layout policies.

(This may also affect the Widgets project...)

A text-based export/import function would be great to support script sharing w/o a version control system such as Monticello or Git.

For example, the fileOut feature in Squeak supports sharing code via forums, email, usb stick, ...

There are handlers and services to invoke code on dropping files from the host system:

Dropping a spreadsheet or csv could open an appropriate script that shows the files content. Then, the user may change that script and explore the dropped data.

I tried to inspect an array containing a file split by lines.
Similiar effect to:

(1 to: 50000) asArray CMD+Shift+e

This is a minor but potentially frustrating problem.

Scenario: I have a code pane which looks like this:

| Class description|
--------------------
| Very long method |





--------------------

If I now add a new method to the class on top. I get the following:

| Class description |
---------------------
| Method template   |

---------------------
| Very long method  |





---------------------

If I place my mouse in the second line of the method template and start typing. The editor with the new method collapses and the editor for the very long method get the focus and I start editing the wrong method.

Using the famous marko image Utilties>>closeAllDebuggers does not close any debuggers. This becomes problematic when having 100+ debuggers ;)

Edit: 'Close all Vivide Windows' is kind of an option, but I'd also lose my arranged editors, so a separate Close all debuggers would be nice.

When I write a script for a new tool it would be helpful to be able to reference steps I store in my profile's organization. These steps (in the profile I use) are probably that useful that I (or somebody else) put them there. So instead of having to copy such a step over to the organization of the new tool I am about to create it would be nice if the tool's organization could simply ask the active profile's organization if it knows a step with the ID I am referencing.

Replace the editor-based debugger with a script-based one. There are already some spikes. Maybe we need to think a little bit more about packaging/deploying tools first.

There seems to be a bug when merging scripts. A script with former "Object" input kind gets "{ PackageInfo. Stuff }" instead. Need to consider number of input parameters!

• Remove block syntax, refactor to (decorating) classes
• Provide means to switch view for given query more quickly
• Maybe show visual preview of view for particular query (stored thumbnails?)

view := View new.
view model: self model.

When re-activating the wizard and re-entering a property extraction snippet, there will be two #isProperty -> true. entries and a debugger will complain about this.

Is there a way to add a method from a Class Outline window? Otherwise it would be nice to have one there. So far, I have been using the 'Add method to class' button at the side of an editor and I might just not have been clever enough to discover another way.

Similar to #17 it is hard to find out that you need another non-property script in the row of scripts in order to create the next deeper level.

This query could provide random input for other queries. Needs concurrent query evaluation.

I wanted to give input from my tool somewhere:

stackOverflow openScriptWith: {aString}.

so I had to do:

self first id: #MyScriptName
self register....

If you do method source containing and a class comment contains the string you get a Key not found Comment error, because #Comment is a valid MethodReference but not correctly handled/looked up by ViObjectService/ViLabelService etc

explicitly disable class comment to temporarily fix this

I dragged my tool from the toolbar, but the output window was not there. To open it, execute from within tool.

self first openScript.

Editing a script (or one of its parts) would be easier if the user could get an indication of the window that is going to update on a change.

Especially in crowded workspaces, where numerous windows battle for the user's attention, a small indication centered around the current keyboard focus would be beneficial.

For each context update, the the script part list will be updated. Opening a single step will detach it from the list automatically.

We have to ensure that all parts in a script are visible when opened.