Gtoolkit 3.10 in Pharo 5.0

We recently integrated GToolkit version 3.10 into Pharo 5.0. This was not a major version, but still there are some notable changes. Here they are.

Senders, References, Messages in GTSpotter

Spotter now includes top-level search processors for finding senders and references. The implementation of senders and references were covered in a previous post. Given that Senders is a common case, we wanted to not have another processor that would start with #S. For this reason we followed the suggestion of David Allouche and renamed the previously existing #Selectors category into #Messages. This way we can use #s shortcuts for spotting senders.

Support for only one matching category in GTSpotter

One issue that popped up during the recent discussions on the Pharo mailing list was that if the search only has matches in one category, the whole result should be inlined in the current step rather than requiring to dive in the category. This is now possible with the excellent work of Stefan Reichhart.

While the change might sound trivial, the implementation was not because it required us to introduce the concept of resumable search processor: after the default search finishes, if there is only one available processor, the search continues where it left off and continues to stream the results.

In essence, this feature means that if you are searching for a specific category you will get all results in one step.

Senders-one-category.png

Manageable extensions for GTSpotter

There has been quite a lot of debate about what processors should exist in Spotter by default and what their semantics should be. Unfortunately, this discussion showed that still it is hard to convince people that Spotter is made to be extended and customized.

One thing that made the problem a bit more complicated than necessary was that Spotter comes by default with 118 extensions. So, if someone would want to provide a different meaning for a processor, this would have meant overriding the corresponding method. This solution was far from elegant.

To solve this, we have taken a different approach and exposed all extensions as settings. The list is computed automatically.

Spotter-extensions-settings.png

If the box is selected, the processor is active. If it is deselected, the processor will not be executed. As simple as that.

This also means that if you want to provide a search for #Messages that is different than the current implementation, you can deselect the current implementation and provide a separate method creating a processors with the same title. Thus, there is no need to override anymore.

And as these are first class settings, you can even export the settings and have your search preferences propagated throughout images. Quite beautiful.

GTInspector works with ProtoObject

One bug discovered recently was that the inspector was unable to work with instances of ProtoObject. Indeed, these kind of objects are not often encountered, but when they appear (for example, when dealing with proxy objects) we want to be able to inspect them. We adapted the GTInspector to handle this case. The support can still be extended, but the current implementation is already reasonable.

Inspector-protoobject.png

GTDebugger offers resize of the stack columns

Another goodie comes from Esteban Lorenzano who gracefully extended FastTable with the possibility of resizing columns. This is particularly useful in the case of large class or methods names.

Debugger-resize.png

Help support for GTInspector and GTSpotter

Both Spotter and Inspector received a help button, and triggering it spawns the associated help. The help is minimal, but the support exists. One of the things provided is the list of all extensions.

Help-spotter.png

Posted by Tudor Girba at 16 February 2016, 10:59 pm with tags gt, moose, pharo link
|