Moose-dev September 2015

moose-dev@list.inf.unibe.ch

33 participants
56 discussions

Re: [Pharo-users] Learning GT - Glamorous Toolkit
by Jimmie Houchin 25 Sep '15

25 Sep '15

Hello Alexandre, I have added moose-dev to this reply. I do not at this time have any particular object models that I require exploring. I have simply watched the videos on the browser, inspector, etc.. Most anything Doru did. :) I am wanting to put a GUI together for a database I am building for my wife. At this point it is simple and will be all contained in the image. This is a pretty conventional thing at this moment. I have done nothing GUI oriented in Pharo and I need to learn those skills. GT seems to be an awesome tool enabling very creative things. At a later date I will have some more adventurous things to try. But my wife's database is where I want to begin learning. Thanks. Jimmie On 09/24/2015 01:11 PM, Alexandre Bergel wrote: > Hi Jimmie, > > Question about GT should be sent to the moose mailing list. > What do you have in mind with GT? Do you have an object model to explore? > > Cheers, > Alexandre > >> On Sep 24, 2015, at 1:57 PM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> >> Hello, >> >> I have watched most all of the videos about GT. >> I am interested in learning how to use the Glamorous Toolkit. >> I am failing to find a beginning place for learning how to use and program GT. >> >> I am probably overlooking it some where. >> I have downloaded the gtoolkit.image to begin learning. >> >> I am currently browsing code to learn what I can from there. >> >> Any advise on documentation or best way to proceed in learning GT greatly appreciated. >> >> Thanks. >> >> Jimmie >>

3 8

FAMIX Documentation?
by Damir Majer 25 Sep '15

25 Sep '15

Hi NG, as I understood the FAMIX is the Metamodell behind MOOSE. Is there any Documentation / Blog / HowTo where the API Model of FAMIX is described? There are some Sucess-Stories with Delphi, Cobol, Java and other Integration of Models, maybe I missed something during my websearch ;-) Best regards, Damir ----- -- Damir Majer ... be agile: www.majcon.de -- View this message in context: http://forum.world.st/FAMIX-Documentation-tp4851789.html Sent from the Moose mailing list archive at Nabble.com.

3 3

Question about MooseChef
by Alexandre Bergel 25 Sep '15

25 Sep '15

hi! Why is there not a method atMethodScope? Also, why is there not a atClassScope? Apparently this method is deprecated and one should use atTypeScope instead. However, a class define a type, but a type does not necessarily defines a class. It may define an interface. I have the impression that atTypeScope and atClassScope are both relevant. We could even introduce atInterfaceScope. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 13

Weird lines implementation
by Yuriy Tymchuk 25 Sep '15

25 Sep '15

Hi everyone, I guess because of a rapid evolution some parts of Roassal are weird. For example RTAbstractLine>>#updateFor:trachelShape: implements the shape drawing, so theoretically RTLine has to only override #trachelShapeClass to return TRLine. Instead RTLine overrides #trachelShapeFor: and does it incorrectly, because width cannot be used as a block but only as a number. We have to handle this somehow, because 1) RTLine works incorrectly. 2) RTLine ignores the implementation strategy coded into RTAbstractLine. Uko

2 5

FM(Null)(Multi)MultivalueLink has confusing printOn:
by Peter Uhnák 24 Sep '15

24 Sep '15

Hi, FM*MultivalueLink has a very confusing printOn: method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FM*MultivalueLink>>printOn: aStream self asArray printOn: aStream ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Converting it to array means that when I see a variable in the inspector it describes itself as array which is quite confusing. Maybe it should be wrapped? printOn: aStream self printNameOn: aStream. aStream nextPut: $(. self asArray printOn: aStream. aStream nextPut: $) Thanks, Peter

3 3

Roassal grapher framed axis?
by Yuriy Tymchuk 23 Sep '15

23 Sep '15

Hi, is it possible to use grapher and not have a 0@0 point in the view? I cannot find this in code nor in examples. Cheers. Uko

2 1

Multi data points in Roassal
by Alexandre Bergel 23 Sep '15

23 Sep '15

Hi! As promised, here is a first try of multi point chart. -=-=-=-=-=-=-=-= b := RTGrapher new. d := RTMultipleData new. d barShape color: Color blue. d points: #( #('hello' 1 2 1) #('world' 2 4 2) #('bonjour' 3 5 4) #('Gutten Morgen' -1 4 -5)). d addMetric: #second. d addMetric: #third. d addMetric: #fourth. "d barChartWithBarCenteredTitle: #first." d barChartWithBarTitle: #first rotation: -30. b add: d. b -=-=-=-=-=-=-=-= Feedback are welcome! @Thomas: The VisualWorks version will follow very soon. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

edge builder - insufficient semantics?
by Tudor Girba 22 Sep '15

22 Sep '15

Hi, Consider this script: view := RTMondrian new. view shape label. view nodes: { 1 . 2 }. view edges objects: { 1 }; connectFrom: [ :x | x + 1 ]. view The expectation is to create 2 nodes and an edge between them. However, the script does not create any edges. The reason is that the collection that is passed to objects: is also used to search the source and target nodes. This is a problem, because this type of filtering is rarely needed. I believe we should keep objects: to only denote the input set of objects that need to be iterated in order to produce the edges. And, if needed, we can add another selector specifically only for filtering (like restrictEdgeSourceToObjects: / restrictEdgeTargetToObjects: ). What do you think? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

2 4

FAMIXNamespace
by Alexandre Bergel 22 Sep '15

22 Sep '15

Hi! Consider the following screenshot: What are Client types? Types are apparently the classes defined in the package. All classes are the sum of the classes defined in all sub-packages. This is rather intuitive :-( Why do we have 'All classes’ ? What does it bring to us? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 5

Following the mouse cursor in Grapher
by Alexandre Bergel 22 Sep '15

22 Sep '15

Hi! I relaxed a bit by implementing something that was missing in Grapher. Consider the following code: -=-=-=-=-=-=-=-=-=-=-=-= b := RTGrapher new. ds := RTDataSet new. ds points: #(5 10 6 2 -2.5). b add: ds. “below is the magic line" b addDecorator: RTCursorFollower new. b -=-=-=-=-=-=-=-=-=-=-=-= This “magic line” add two bar that follows the mouse cursor. Here is a screenshot: Here is on a larger example: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | methods trachelMethods b ds | methods := Collection withAllSubclasses flatCollect: #rtmethods. trachelMethods := TRObject withAllSubclasses flatCollect: #rtmethods. b := RTGrapher new. b extent: 200 @ 200. "Data set 1" ds := RTDataSet new. ds interaction popup. ds dotShape circle color: (Color red alpha: 0.3). ds points: methods. ds x: #numberOfLinesOfCode. ds y: [ :m | m getSource size ]. b add: ds. "Data set 2" ds := RTDataSet new. ds interaction popup. ds dotShape circle color: (Color blue alpha: 0.3). ds points: trachelMethods. ds x: #numberOfLinesOfCode. ds y: [ :m | m getSource size ]. b add: ds. b axisX withThousandsSeparator; title: 'LOC'. b axisY noDecimal; title: 'Size'. b addDecorator: RTCursorFollower new. b build. ^ b view -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Maybe this cursor follower should be per default in all produced chart. Any opinion? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2015