Hi!
Leo, double clicks have been added to Roassal :-)
-=-=-=-=-=-=-=-=-=
| v es |
v := RTView new.
es := (RTBox new color: Color purple; size: 25) elementsOn: (1 to: 100).
es when: TRMouseDoubleClick do: [ :e | e element trachelShape color: Color red. v signalUpdate ].
v addAll: es.
RTGridLayout on: v elements.
v open.
-=-=-=-=-=-=-=-=-=
This is a contribution from Juan-Pablo Sandoval
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Name: Famix-SourceAnchor-usmanbhatti.44
Author: usmanbhatti
Time: 8 August 2014, 3:43:01.966938 pm
UUID: 2e5e4d96-f927-4a96-9b6e-e8f0e1507eae
Ancestors: Famix-SourceAnchor-VincentBlondeau.43
adding FAMIXMultiFileAnchor, a source anchor for entities defined in
multiple files. It has a collection of FAMIXFileAnchor objects which point
to the individual definition files. It makes sure not to duplicate
FAMIXFileAnchor with similar names/paths to optimize memory. SourceText
returns the string of all FileAnchor contents with a separator line
between them.
To create, Use FAMIXSourcedEntity>>defineMultiSourceAnchorWithPath:. See
tests.
Name: Famix-Tests-Core-usmanbhatti.46
Author: usmanbhatti
Time: 8 August 2014, 3:45:48.287238 pm
UUID: 18bdabf9-815a-49b4-b0bd-7716f1220436
Ancestors: Famix-Tests-Core-TudorGirba.45
adding tests for multiple file anchor.
======================
Moose build is as unstable at it was before this change.
Hello
I am trying GET2 pieDiagram builder. You may want to add a random color in
the #pieExample method so it looks nicer (see attachment):
| diag |
diag := GET2DiagramBuilder new.
(diag pieDiagram)
models: #(30 10 20 40);
color: [ Color random ].
^ diag open.
Now my question is simple, but I don't know how to start
How would you add labels to each sector?
Hernán
The following test is red, because apparently RTTable does not parse
CSV correctly (commas inside quotes should not be considered as
delimiters).
NeoCSV parse this kind of String without problems.
===========================================================
RTTabTableTest>>testCommasInsideQuotes
tab
input:
'2014-01-26 00:00:00+00,Boeing 737-3B7 (SF),ZK-TLC,"Airwork, NZ,
opf. Pacific Air Express",0,Honiara-Henderson International Airport
(HIR),Solomon Islands,-9.428056,160.053056,"Brisbane International
Airport, QLD (BNE/YBBN), Australia","Honiara-Henderson International
Airport (HIR/AGGH), Solomon Islands",Accident resulting in a total
loss of the plane,0101000020E6100000691B7FA2B201644091B6F1272ADB22C0,7,2014-07-18
11:46:49.32676+00,2014-07-18 11:47:01.156893+00'
usingDelimiter: $,.
self assert: tab numberOfColumns equals: 16
===========================================================
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
Hi,
I am trying to create a transmission in my browser where a destination port
can be populated form a #selection and #strongSelection source port. It
seems to be that transmission does not occur correctly from
#strongSelection port to the destination port.
To reproduce, in the browser produced by the sample below, double clicking
in the right pane should show the elements up to the selected integer. But
in my case, there is no change in the centre pane.
| browser |
browser := GLMTabulator new
column: #one; column: #two; column: #three; yourself.
browser
transmit to: #one;
andShow: [ :a | a list display: [ :x | 1 to: x ]].
browser
transmit to: #two;
from: #one;
from: #three port: #strongSelection;
andShow: [ :a | a list display: [ :x | 1 to: x ]; allowNil].
browser
transmit to: #three;
from: #one port: #strongSelection;
andShow: [:a | a list display: [ :x | 1 to: x ].].
browser openOn: 100
Is it a bug or wrong usage of transmissions? What is the best way to
populate a destination from multiple origin ports and amongst those one is
#strongSelection.
Thanks.
usman
Hi,
The GTInspector now shows the state of an object in a tree view
(screenshots below).
This tree view focuses on the internal structure of an object.
For example, when looking at a dictionary object you will see the "array"
and the "tally"
attributes and not the key value pairs. Those can be accessed from another
presentation
of a dictionary object.
So the tree is meant to be used together with the finder and the other
presentations of on object.
Let us know what you think.
Cheers,
Andrei & Doru
[image: Inline image 1]
[image: Inline image 2]
Hi again,
I will be using this thread to update my advances and questions about
how to build an outliner in Pharo Smalltalk. If there is a better method
like starting a new thread for particular questions, or a less narrative
style, please let me know.
The idea is to use the tools provided by Moose to build a quick outliner
that can be extended to suit my needs on academical writing. This is
kind of a strange approach in the sense that I'm not following the
tutorials with a predefined problems (make a game and so) but trying to
start with a real (in the sense of closer) problem (making an outliner)
and to see which knowledge I need to solve this necessity. In that sense
is more like the Freire's alphabetization of adults in Brazil.
So, the things I have done so far was to search for a good model to
start with. Something already done that can be used as scaffolding for
my outliner. The Help System seems like a good start for an outliner (in
fact it is already one), so I have taken the Help-Core system and start
to use it as a base for my project.
After that I have used the Moose browsers to build a simple interface,
as seen here:
http://mutabit.com/offray/static/blog/output/galleries/objetos/ubakye-brows…
The part I want to deal with is this:
===============
explorer := GLMTabulator new
title: (mainTree header).
explorer column: #tree;
column: #body.
explorer transmit to: #tree; andShow: [:a |
a tree
display: mainTree children ].
explorer openOn: mainTree.
===============
So, instead of "display: mainTree children" I need something that takes
the get names (headers) of the two nodes and the contents in the right
panel. For that I think that I need to learn some iterators. I have
already a "header" method for the nodes. Any clue would be appreciated
and I will keep you posted on my advances.
Cheers,
Offray
On 07/21/2014 12:58 PM, Offray Vladimir Luna Cárdenas wrote:
> Hi Damien,
>
> Thanks for your answer. Comments below.
>
> On 07/21/2014 11:09 AM, Damien Cassou wrote:
>> On Sat, Jul 19, 2014 at 2:47 AM, Offray Vladimir Luna Cárdenas
>> <offray(a)riseup.net> wrote:
>>> The first idea that comes to mind is using STON for storage nodes and
>>> tree
>>> information, so I can interchange it with the flatland files world
>>> and keep
>>> it readable. Sounds that reasonable?
>>
>>
>> without more information, it is hard to stay. Try with STON and change
>> if that does not work :-). We have XML and JSON generators as well.
>>
>
>
> This is a kind of raw preview of I'm talking about:
>
> http://www.enlightenment.org/ss/e-53cd4f36f021e9.68569046.jpg
>
> Of course in this case, it is just a Help browser with a Playground
> window over it, but I would like to have something like Playgrounds
> inside the help browser. I was trying to build a custom browser with
> Glamour, but seems that Help Browser already has the machinery I'm
> looking for.
>
> So my first question is how to use the Help Browser class as a template
> for my outliner class? And can I put a Playground where the plain text
> is located right now?
>
>>
>>> The second thing I would like to do is to add pandoc's markdown inside
>>> comments, but I don't like the syntax of comments in Smalltalk because
>>> single quotes are fairly easy to find in light markup language like
>>> markdown. Is difficult to change it to create something more like python
>>> (with """) or Lua (with -[]- )?
>>
>>
>> There is only one syntax for comments in Pharo. Instead of Markdown,
>> you might want to have a look at Pillar which is implemented in Pharo
>> and can generate Markdown (and html, and pdf) :
>> https://github.com/pillar-markup/pillar-documentation/
>>
>>
>
> I have seen Pillar. Seems really interesting, but Pandocs markdown
> support academic citation in several formats and I have already long
> docs wrote on that format integrated in my workflow from Zotero and even
> there is a growing community working on Scholarly Markdown[1][2] so I
> would like to stick with it as much as I can for my own writing.
> That being said. I would like also a better integration between
> Smalltalk outliners and all the academic publication work flow,
> including working better with pandoc as a external library.
>
> [1] https://github.com/scholmd/scholmd/wiki
> [2] http://blog.martinfenner.org/2013/06/29/metadata-in-scholarly-markdown/
> [3]
> http://programminghistorian.org/lessons/sustainable-authorship-in-plain-tex…
>
>
> Thanks again, this conversation with people in the community is very
> valuable to me,
>
> Offray
>
>
Dear All,
This week end has been intense for Roassal (yeah, I got a flu, so I stayed home :-)
Two major improvements of Roassal: Pie builder and Builder composition have been added.
I will send a post about the pie builder later on. In this email I want to discuss the composition. Here is an example of builder composition:
The code is available from RTComposerExample>>exampleClassAnalysis
The cool thing, is that highlights are propagated across different builders. This means that you can globally highlight some elements.
The class RTComposer is actually quite simple.
Here is a short and simple example, in which code dedicated to the composition is indicated in bold:
-=-=—=-=-=—=-=-=—=-=-=—=-=-=—=
classes := Collection withAllSubclasses.
c := RTComposer new.
b1 := RTMondrianViewBuilder new.
b1 view: c view.
b1 nodes: classes.
b1 gridLayout.
b1 build.
c propagateHighlight.
c group: #hierarchy.
b2 := RTCharterBuilder new.
b2 view: c view.
b2 extent: 200 @ 200.
b2 points: classes.
b2 allY: #numberOfMethods.
b2 stackX.
b2 curve.
b2 axisX.
b2 axisYWithNumberOfTicks: 4.
c propagateHighlight.
c group: #curve.
c move: #hierarchy above: #curve.
c open
-=-=—=-=-=—=-=-=—=-=-=—=-=-=—=
This is still early work. Many more things have to be improved. For example, the layout of builder is quite simple. Maybe we will need something more complex. The propagation of events may also be improved.
Feedbacks are welcome. This is a crucial point of Roassal, and it has to be done right.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.