I'm using RTLegendBuilder to compare some insurance options. Cool! I was quickly able to cobble together a reasonable legend and align it to any side of my graph :) <http://forum.world.st/file/n4813331/Screenshot_2015-03-19_15.png> As I tweaked, though, I noticed a few things: - Luckily, my domain object's printString is what I want for the label of the legend item. Thus I am able to pass it to #addColor:text: (which I took a while to figure out can take any object for "text:"). I want to pass this object, and not just the label text I want, because that would break the GT Inspector flow. I think there is a missing dimension here for when we want the item and the label to be different. In fact, drop lists in Pharo used to work like this. I think the pattern is carried over from less dynamic or OO languages. In Magritte3, I added #display: to field descriptions of the form [ :domainObject | stringFormToUse ] - #addColoredText:color: and #addColor:text: - do we really need both? I know it's considered best practice to implement: simple: simple:intermediate: simple:intermediate:complicated: style APIs, but I strongly prefer one method that takes a domain object which already has all this info, even at the expensive of a pair of parentheses. OT: Text builders seem inherently restrictive because they always seem to insert a layer between the full power of the underlying objects and the part that's been translated to the builders. I sense that it would be a game changer (and not too hard) to hook the underlying objects together visually a la Lively Kernel instead of implementing a visual or text builder. In fact, I think that's what e.g. Morphic almost-already-is. It was even alluded to in a few papers as right on the horizon. But it's on the Dreams list for now. Anyway, thanks for Roassal. This is fun! ----- Cheers, Sean -- View this message in context: http://forum.world.st/RTLegendBuilder-Questions-tp4813331.html Sent from the Moose mailing list archive at Nabble.com.