RTLegendBuilder Questions
Locked
RTLegendBuilder Questions
 
Administrator
|
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 :)
 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 |
Re: RTLegendBuilder Questions
|
|
Hi Sean!
- Luckily, my domain object's printString is what I want for the label of I have never thought about having the legend to contains meaningfull object. Are you suggesting something like: #addColor:object:text: that will collocate the object being the legend label and colored box? - #addColoredText:color: and #addColor:text: - do we really need both? They are two different method. Consider: b := RTLegendBuilder new. b addColor: Color red text: 'a legend title'. b addColoredText: 'a legend title' color: Color red. It gives:  Maybe the names are not properly chosen. If you have better ones, would be great :-) OT: Text builders seem inherently restrictive because they always seem to I am not sure to understand. Which text builder are you referring to? Anyway, thanks for Roassal. This is fun! Thanks :-) Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: RTLegendBuilder Questions
|
Administrator
|
Yes. I'd like a way to specify the object, and either a block or selector to get its display string. It all came quite by accident. Since you can drag the legend around, I started thinking of it as a live object. So I clicked on one of the labels, and the label's text appeared in the right-most pane of the GT Inspector. Then I thought, "if I put the underlying domain objects in the legend, shouldn't I then be able to inspect them in GT?!" And it worked! I made a tiny screencast https://www.youtube.com/watch?v=N1u807ij1p8
Ah, now I see. I will think about the names...
Sorry, that was /way/ OT. I was dreaming about constructing visualizations by direct manipulation instead of coding.
Cheers,
Sean |
Re: RTLegendBuilder Questions
|
|
Re: RTLegendBuilder Questions
|
Administrator
|
| Free forum by Nabble | Edit this page |