Hello, Below is a mashup of the Roassal Examples Nesting and Pie Chart builders that gives the basic flavor of what I am trying to accomplish. Notice that I am creating new PieBuilders every time, running them, and extracting their createdElements for my layout. This works well enough, but if I then want to normalize global properties so that all pie slices with the same property get the same color, I have no way to coordinate the newly generated PieBuilders, as each possesses its own normalizer. Likewise, if I have a global PieBuilder, its internal state gets trampled with each iteration. I figured there was likely an easy way to compose builders that I didn't know about, so I thought I would ask. | v es b | v := RTView new. es := RTEllipse elementsOn: RTShape withAllSubclasses. v addAll: es. RTNest new for: es add: [ :group :model | b := RTPieBuilder new. b objects: RTShape withAllSubclasses. b slice: #numberOfMethods. b normalizer distinctColor. b view: v. b build. group addAll: b createdElements. ]. RTCellLayout new lineItemsCount: 8; on: es. v |
Hi Evan,
You are indeed on the edge of what Roassal can do. This is a situation that I have tried to fix. Please play with the solution I propose and complain if this is not what you expect. Try this: -=-=-=-=-=-=-=-=-=-=-=-= v := RTView new. es := RTShape withAllSubclasses collect: [ :cls | b := RTPieBuilder new. b interaction popupText. b objects: cls withAllSuperclasses. b slice: #numberOfMethods. b normalizer distinctColor. b build; asElement. ]. v addAll: es. RTCellLayout new lineItemsCount: 8; on: es. v -=-=-=-=-=-=-=-=-=-=-=-= It produces the following Now, you can send the message #asElement to a builder or a view. This message returns a "compound element” (something new I have recently introduced) which can freely be added to a view. Is this what you expect? It is likely that this mechanism will be a foundation of Roassal3 as nesting is a recurrent need. Cheers, Alexandre On Mar 17, 2016, at 9:59 PM, Evan Donahue <[hidden email]> wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Hello,
Many thanks for the reply. This indeed solves part of my problem, and does what I expect (although in the smalltalkhub / ObjectProfile / development code, only RTView has #asElement, not RTBuilder). Given this, I think I can give an example of the real stumbling block I'm facing (although whether it is a framework limitation or my own ignorance, I cannot say). Note that in the following code, there are two solid pie charts of the same color, but each represents a different object (the numbers 1 and 2 respectively). This is happening because each pie chart is generated with its own normalizer. Is it possible to share a single, global normalizer across many pie charts, or set up a single pie builder outside of the loop and then only vary its objects? I would like every slice in every pie chart that represents the number 1 to be one color, and every slice representing the number 2 to be a different color. Which color they are does not matter so long as they are distinct, and I will not know ahead of time how many different colors I will need or what types of objects I will be representing, so I can't manually assign colors to categories. v := RTView new. data := #((1) (2) (1 2)). es := data collect: [ :d | b := RTPieBuilder new. b interaction popupText. b objects: d. b slice: #value. b normalizer distinctColor. b build. b view asElement. ]. v addAll: es. RTCellLayout new lineItemsCount: 3; on: es. v Thank you, Evan |
Hi!
In that case you can create a normalizer and use it after all the elements have been added. For example (__you need to update Roassal since I’ve just fixed a bug__): -=-=-=-=-=-=-=-=-= v := RTView new. data := #((1) (2) (1 2)). es := data collect: [ :d | b := RTPieBuilder new. b interaction popupText. b objects: d. b slice: #value. b build. b view asElement. ]. v addAll: es. RTCellLayout new lineItemsCount: 3; on: es. RTMetricNormalizer new view: v; objects: #(1 2); distinctColor. v -=-=-=-=-=-=-=-=-= If you do not know what are the values you have added in, you cannot provide “objects: #(1 2)”. In that case, you can simply do: -=-=-=-=-=-=-=-=-= v := RTView new. data := #((1) (2) (1 2)). es := data collect: [ :d | b := RTPieBuilder new. b interaction popupText. b objects: d. b slice: #value. b build. b view asElement. ]. v addAll: es. RTCellLayout new lineItemsCount: 3; on: es. RTMetricNormalizer new view: v; elements: v elements; distinctColor. v -=-=-=-=-=-=-=-=-= Let us know how it goes! Cheers, Alexandre > On Mar 18, 2016, at 5:49 PM, Evan Donahue <[hidden email]> wrote: > > Hello, > > Many thanks for the reply. This indeed solves part of my problem, and does > what I expect (although in the smalltalkhub / ObjectProfile / development > code, only RTView has #asElement, not RTBuilder). Given this, I think I can > give an example of the real stumbling block I'm facing (although whether it > is a framework limitation or my own ignorance, I cannot say). > > Note that in the following code, there are two solid pie charts of the same > color, but each represents a different object (the numbers 1 and 2 > respectively). This is happening because each pie chart is generated with > its own normalizer. Is it possible to share a single, global normalizer > across many pie charts, or set up a single pie builder outside of the loop > and then only vary its objects? I would like every slice in every pie chart > that represents the number 1 to be one color, and every slice representing > the number 2 to be a different color. Which color they are does not matter > so long as they are distinct, and I will not know ahead of time how many > different colors I will need or what types of objects I will be > representing, so I can't manually assign colors to categories. > > v := RTView new. > data := #((1) (2) (1 2)). > es := data collect: [ :d | > b := RTPieBuilder new. > b interaction popupText. > b objects: d. > b slice: #value. > b normalizer distinctColor. > b build. > b view asElement. > ]. > > v addAll: es. > RTCellLayout new lineItemsCount: 3; on: es. > v > > Thank you, > Evan > > > > -- > View this message in context: http://forum.world.st/Nesting-Builders-in-Roassal-tp4885185p4885372.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Hello,
I got that working, and a bit more besides, and things are starting to look pretty good. However, I've run into another issue I'm not sure how to resolve. Recognizing that, as you mentioned, nested builders are something of a bleeding edge feature, I'm happy to try to contribute code if what I'm trying to do isn't already implemented. My question now is how to adjust the size and shape of the nested, builder-produced elements. In the example code you posted, is it possible to 1) remove the square borders from the pie graphs, and 2) make the pie graphs different sizes based on, for instance, the size of the array they represent? This second question is also relevant for sizing the pie graphs in proportion to other elements such as labels. Witness the uneven proportions between the pie charts and a label added to the display: v := RTView new. data := #((1) (2) (1 2)). es := data collect: [ :d | b := RTPieBuilder new. b interaction popupText. b objects: d. b slice: #value. b build. b view asElement. ]. v add: (RTLabel new elementOn: 'label'). v addAll: es. RTCellLayout new lineItemsCount: 3; on: es. RTMetricNormalizer new view: v; elements: v elements; distinctColor. v Normally, I gather, this is done by adding size and shape info to the element factory before it produces its elements. Since the builders do not appear to have been intended to fill this role initially, however, I can't seem to find any corresponding inputs for size or shape of their generated elements as nested in another builder's view. Cheers, Evan |
Free forum by Nabble | Edit this page |