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 composedadd: #aModel;yourselfMyClass>>changeLayoutDynamicallyself buildWithSpec: #myDynamicLayout.Then you can add:aComposableModel needRebuild: falseon 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 <chisvasileandrei@gmail.com>
> Hi folks, while working on the new debugger, I've come up with some questions...I do not get your question ...
>
> *is there any other implementation for dynamic widgets other that the current one?
This is related to my previous question about dynamic spec, if it's possible to define the layout ofa widget on the object side.�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).
>
> *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?
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?�