Hello,
So in the current spec debugger, the receiver's inspector widget is changed
dynamically. Even if it looks like the same because it is always an
inspector, it is not the same widget (could be any subclass of EyeInspector
depending on receiver's type). So it is possible to change the main
debugger spec dynamically object side.
To change dynamically you have to do something like:
MyClass class>>myDynamicLayout
<spec>
^ SpecLayout composed
add: #aModel;
yourself
MyClass>>changeLayoutDynamically
self buildWithSpec: #myDynamicLayout.
Then you can add:
aComposableModel needRebuild: false
on some widgets not to rebuild them and to speed up the spec generation.
However, as this was too slow to do it for the full debugger (in the case
of the receiver inspector), an inspectorWrapper class was made so the
debugger has fixed spec and only the inspector wrapper spec changed.
Depending on how often you change the toolbar, you may need to do something
similar, even if it's a bit overly complex.
You can have a look at inspectorWrapper, in Pharo 3.0.
(InspectorWrapper>>updateInspectorFrom:)
Hope it helped you,
2013/7/10 Andrei Vasile Chis <[email protected]>
>
> > Hi folks, while working on the new debugger, I've come up with some
>> questions...
>> >
>> > *is there any other implementation for dynamic widgets other that the
>> current one?
>>
>> I do not get your question ...
>>
>
>
> This is related to my previous question about dynamic spec, if it's
> possible to define the layout of
> a widget on the object side.
>
>
>>
>> >
>> > *right now the toolbar is a static widget, and I would like to have a
>> dynamic one to filter out the actions that should not be available (which
>> are a subset of the default ones). Would it make sense to regenerate the
>> toolbar everytime the selection changes? Is there any other approach I
>> should consider?
>>
>> It may make sense to dynamically regenerate the toolbar (or at least
>> remove only what needs to be removed, add only what needs to be added).
>> Then you should also think in term of user experience. Having things
>> changing may be disturbing and counter productive :)
>
>
> Right now our use case are post mortem contexts (that do not have a
> process attached). In there case only few actions make sense.
> The current debugger sets the toolbar at the creation of the debugger. If
> the context turns post mortem during debugging the actions should also
> change. Now the question would be if this is actually possible?
>
>
>
