Extending Bloc to handle new backends and hosts

Bloc is the new graphical engine for Pharo initiated several years ago by Alain Plantec. It is an ambitious project that has as goal the complete overhaul of the rendering in Pharo starting all the way from the basics of drawing. The project underwent at least 4 distinct redesigns and you can read some of its history on the GitHub page.

This post is about a new milestone that was reached recently.

At the very basis of Bloc, there exist a canvas called Sparta. Sparta was released last year and was developed by Aliaksei (Alex) Syrel. At the time, Sparta offered highly performant rendering by relying on a stripped version of Moz2D and an SDL window. While the rendering is remarkable in terms both of speed and of beauty and flexibility, the community still raised the issue of having to depend on yet another external library (Moz2D) that had to be stripped down.

Indeed, this can pose a risk in the long term. It would have been much better to be able to provide some way of rendering Sparta on top of the current solution provided by Morphic and Cairo even if the rendering would not be as pretty.

It is at this moment that the investment of having thrown away all those working versions that were not quite good enough paid off. Based on the work of Glenn Cavarle to decouple the backend and host from the main Bloc logic, Alex implemented a new solution to get Sparta to work with the Cairo backend inside Morphic as host. For example, the following screenshot shows how rendering on the two backends looks like inside a Morphic host:

As the screenshot reveals, the basic rendering is similar, while the advanced effects, such as blur, are only available in the Moz2D backend. Similarly, when displaying fonts, there might be differences due to Cairo being less adept at finding all fonts:

The choice between the different backends and hosts can be adjusted via two settings available in the Settings Browser.

To load the Bloc, you can use two scripts in Pharo 6.0.

To load a minimal Bloc relying only on Cairo and Morphic, please use:

Metacello new
 baseline: 'Bloc';
 repository: 'github://pharo-graphics/Bloc/src';
 load:#core

To load the Bloc code that also relies on SDL2 and Moz2D, including the virtual machine plugin for Moz2D:

Metacello new
 baseline: 'Bloc';
 repository: 'github://pharo-graphics/Bloc/src';
 load:#development

All in all, this now implies that the backend and host windowing system are no longer a liability, and that we can safely invest in building the future Pharo graphical user interface on top of Bloc.

Introducing gt4gemstone

feenk.com is proud to announce gt4gemstone, a version of the Glamorous Toolkit aimed at supporting remote development with GemStone/S, the coolest object-oriented database in the world, from Pharo. gt4gemstone is released as an open-source project under the MIT license and was built primarily by Andrei Chis with some marginal contributions from me.

The toolkit currently offers several features:

• Remote Playground
• Remote Inspector with extensions that can be coded exactly like the ones in Pharo
• Remote Debugger with mixed stacks (Pharo and GemStone)
• Basic Remote Code Browser
• Remote Session Handler
• Integration with Roassal
• A Glamour-specific proxy model for efficient serialization of Glamour presentations
• A basic proxy model for working with any remote objects from GemStone

There are still things to improve, especially around code browsing and searching, but the tools can already support development scenarios.

One particular aspect that we focused on is performance. So much so, that at one point inspecting objects in gt4gemstone was faster than doing them locally. In the meantime, the GT inspector from Pharo also received an upgrade.

But, perhaps the most exciting thing about this project is that most extensions of the inspector can be expressed exactly in the same way both in Pharo and in GemStone.

For example, this method defines an extension for an AddressBook class.

ABAddressBook>>gtGsInspectorAContactsOn: aComposite
   <gtInspectorPresentationOrder: 5>
      aComposite table
         title: 'Contacts';
         display: [ self contacts ];
         column: 'Name' evaluated: [ :aContact | 
            aContact fullName ] width: 150;
         column: 'Telephone' evaluated: [ :aContact | 
            aContact address telephone fullNumber ]

Inspecting an instance of such a class locally offers a custom presentation in the inspector:

But, after deploying the class in Gemstone, the same method offers the custom presentation in the remote inspector as well.

Why is this feature important? When programing in Pharo, extending the inspector is by now an expected feature and it is part of the typical development flow. It is only natural to expect the same ability when inspecting remote objects.

With the ability of having the same code working both in Pharo and in GemStone, the scenario of building in Pharo and deploying in GemStone even more appealing.