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.