There are a number of separate problems here, I think. Mixing them up
makes the situation a bit complex. I'll try separating them here.

At what abstraction level should the basic tools be build. From my point 
of view, Glamour provides the right level. It is very easy to build browsers
and it is easy to keep them maintainable. When the underlying stack is
going to be replaced it makes sense to have an abstraction layer that is
is easy to implement on both the old and the new stack. The alternatives
(Morphic, PolyMorph, OmniBrowser, ToolBuilder) are much less accessible. 
OmniBrowser looks much more comprehensive, but I don't feel qualified
to comment on its usability as abstraction layer. I have taken a look at 
creating a google issue browser with Glamour (before ssl support) and
think the committer workflow should be able to be improved with a few
specialized Glamour browsers. But my opinion does not matter so much. 
That decision should be taken by the people maintaining the core of Pharo. 

Does Glamour provide enough functionality to build a whole tool chain?
The focus of Glamour is on navigation in a single window, the language
for updating and editing is limited. Drag-and-drop support is missing.

Should the programming style of Glamour be the style to build basic tools 
in Pharo? Would it be better to use something more similar to the Seaside
canvas style? The behavior change based on the number of block 
parameters is very powerful but imho also confusing. On the other hand 
I'm pretty sure HelpBrowser initWindow is worse than the equivalent 
Glamour code would be.

At the moment the modularization of Pharo is not yet good enough. It is
not easy enough to (de)compose images, so the maintainers need to have
in the core image code to create user interfaces (web-based :) or direct).
When we can create very small images and work with them using remote 
tools, this need will disappear. 

Committing to a tool chain build on top of Glamour would mean either
back porting Glamour to earlier versions of Squeak/Pharo, so the new
tools can replace the old ones everywhere, or breaking old tools and
having to maintain them all ourselves. That is, if current maintainers 
agree with that.

Happy new year,
  Stephan

Reply via email to