Hi. I need to have larger fonts for the legends of a DistributionMap. For
example, in the attached screenshot I would like to use bigger fonts for the
properties and for the packages names.
Is that possible? I surf a little the code but I didn't find anything.
Thanks in advance,
Mariano
On Nov 3, 2010, at 10:17 AM, Tudor Girba wrote:
> Hi Stef,
>
> Thanks for pushing this.
>
> I definitely understand these issues, and a solution will follow in the near future. It is just a matter of effort, and until now the main goal was to get things going at the model level. This is now working quite well, so now it's time to focus on the rendering and on the API.
good to hear that.
> The only thing is that the API will only grow from people using it. With Mondrian, we could do it by having it used by a small amount of people. Glamour is a more complicated engine, and getting the right API right is not as straightforward. What you have right now is already the third version.
I imagine
> The rest of the comments are inlined.
>
>> I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools
>> with glamour. Alain told me that he will have a look too.
>>
>> Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves
>> and that was frustrating: mismatch of block arguments or something like that.
>
> This was a mismatch of the returned type.
Still the point is how can we make sure that we can debug it because the model is aligned with our mental model.
>
>> This is this aspect of glamour that I would like to see lowered.
>> You see even reading your answer and looking at the code I do not get it. :(
>>
>> then some questions:
>>
>> why children: [:item :x :level |
>>>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]].
>>
>> could not be
>>
>> child: childObject level: level....
>
> Basically, for every item, we want to know how to build the children collection. When you need to reason about multiple things, you need to pass them as a parameter in the block.
>
> Perhaps we can have something like:
>
> children: aBlock
> children: aBlock atLevel: anInteger
> children: aBlock atLevelHigherThan: anInteger
Yes
>> I have no idea what is x.
>
> in this case, the second variable is not used inside the block, so I just marked it with x to document that fact. The object is the presentation object.
This is an hidden assumption and without an example I would have no idea that I should pass 3 arg block.
Blocks used at their limits are evil since they do not have names.
>> So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context.
>> So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having
>> less scripting and more programming api would help).
>
> The blocks are just a convenience to construct and parameterize your presentations. Of course, this is only one way, and not the only way :). There really isn't anything magic about it. But, as I said, I will follow with another mail in the following days.
Good.
I'm eager to see that.
Now consider that your focus should not be on scripting (you have that API) but on how to build classes and use
the power of classes to achieve build the same browsers.
Hi,
just to announce that following Doru's suggestions I added/changed
some features to VerveineJ:
- primitive types are exported as Famix PrimitiveType
- interfaces are exported as Famix Class with the isInterface flag set to true
- entities outside the parsed source code (libraries, etc.) are
flagged as stubs (except the PrimaryTypes which are outside the parsed
code anyway)
- opened some issues (see below) in the google-code page for verveine
(should create a Component-Verveine to simplify entering issues)
Yet to be done:
- create a Famix Interface entity: requires changing the meta model so
I will wait a bit for that
- compute and export some metrics (probably the next one on my list)
- in FileAnchors store the relative path to the code instead of fullpath
- export exceptions
- export annotations
- set next/previous for the associations
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
doru
I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools
with glamour. Alain told me that he will have a look too.
Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves
and that was frustrating: mismatch of block arguments or something like that.
This is this aspect of glamour that I would like to see lowered.
You see even reading your answer and looking at the code I do not get it. :(
then some questions:
why children: [:item :x :level |
>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]].
could not be
child: childObject level: level....
I have no idea what is x.
So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context.
So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having
less scripting and more programming api would help).
I understand that right now you want to script your browser in a workspace. But when the script gets bigger and gets hosted in a class
then not using method is frustrating. so having an API for scripting is one point but it would be good to have the counterpart when we
code class because at the end we will code classes.
Stef
> Hi Benjamin,
>
> First of all, welcome :).
>
> Second of all, thanks for reminding me that I should update the examples with using the new API, instead of the old one that uses showOn:. I committed a quick update of the treeWithChildrenByLevel to give you an idea of the difference.
>
> Coming back to your example, the problem is that the children block does not return a collection, but an integer. If you want to see the children of a node, you need to specify a collection with objects that will appear as children. Ideally, they should be of the same type as the root nodes.
>
> Cheers,
> Doru
>
>
> On 2 Nov 2010, at 19:12, Benjamin wrote:
>
>> Hi everybody,
>>
>> I'm just discovering Glamour, and after having read examples, I've tested to write my own browser but, as you guessed, it doesn't work and moreover the debugger doesn't help me at all
>>
>>
>> Here is my code :
>>
>> recentSetBrowser
>> | browser |
>>
>> browser := GLMTabulator new.
>> browser column: #one.
>> browser showOn: #one; using: [
>> browser tree
>> title: 'Tree';
>> children: [:item :x :level |
>> level > 1 ifTrue: [#()] ifFalse: [item size ]]].
>> ^browser
>>
>> Here is the example :
>>
>> treeWithChildrenByLevel
>> |browser |
>>
>> browser := GLMTabulator new.
>> browser column: #one; column: [:c | c row: #two; row: #three].
>> browser showOn: #one; using: [
>> browser tree
>> title: 'Tree';
>> children: [:item :x :level |
>> level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]].
>> browser showOn: #two; from: #one; using: [ browser text title: 'Selection preview' ].
>> browser showOn: #three; from: #one->#selectionPath; using: [
>> browser text title: 'Selection path preview'].
>> ^ browser
>>
>> When I run
>> GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau')
>> the debugger answer :
>> 'MessageNotUnderstood: SmallInteger>>collect:' ...
>>
>> If someone can help me :)
>>
>>
>>
>>
>>
>> Benjamin Van Ryseghem
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Live like you mean it."
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi everybody,
I'm just discovering Glamour, and after having read examples, I've
tested to write my own browser but, as you guessed, it doesn't work
and moreover the debugger doesn't help me at all
Here is my code :
recentSetBrowser
| browser |
browser := GLMTabulator new.
browser column: #one.
browser showOn: #one; using: [
browser tree
title: 'Tree';
children: [:item :x :level |
level > 1 ifTrue: [#()] ifFalse: [item size ]]].
^browser
Here is the example :
treeWithChildrenByLevel
|browser |
browser := GLMTabulator new.
browser column: #one; column: [:c | c row: #two; row: #three].
browser showOn: #one; using: [
browser tree
title: 'Tree';
children: [:item :x :level |
level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]].
browser showOn: #two; from: #one; using: [ browser text title:
'Selection preview' ].
browser showOn: #three; from: #one->#selectionPath; using: [
browser text title: 'Selection path preview'].
^ browser
When I run
GLMTest1 new recentSetBrowser openOn: #('lapin' 'chapeau')
the debugger answer :
'MessageNotUnderstood: SmallInteger>>collect:' ...
If someone can help me :)
Benjamin Van Ryseghem
Hi,
i have a problem with the moose panel: when i load my stuff (MooseJEE) i have a group of database tables which has defined on top 2 visualizations. When i load a model form a MSE file, the first time that i click on that entity it is actually recognized has a TableGroup (see figure 1). When i click a second time on it it not consider anymore a TableGroup but just a MooseGroup, consequently i loose all the information specifically related with the table group (see figure 2).
I define my group like this:
mooseModel>>>allTables
<navigation: 'All Data Base Tables'>
| group |
group := self allWithType: MJFAMIXTable ofGroupClass: MJFAMIXTablesGroup.
group description: 'All Data Base Tables'.
^group
SessionBeans group has the same definition but it works all the time.
Any ideas on which could be the problem?
Cheers,
Fabrizio
We do not want that.
Stef
> Ok, this an old thread, but I found that this idea was already implemented in Pharo:
>
> http://www.youtube.com/watch?v=n4I7fSVNX2A
>
> In order to use it you need to execute:
>
> MCHttpRepository
> location: 'http://www.squeaksource.com/Environments'
> user: ''
>
> password: ''
>
> I tested it and it works. It only applies to classes that you explicitly define in a package and you need to use a new system browser that is package aware.
>
> What do you think about using this on Moose instead of having class prefixes?
>
> Cheers,
> Guillermo.
>
> On Tue, Sep 28, 2010 at 9:16 AM, Guillermo Schwarz <guillermo.schwarz(a)gmail.com> wrote:
> Hi Guys,
>
> Why don't you do something more focused on the long term and don't you change the Smalltalk compiler with namespaces?
>
> I don't think it should be that hard since each class already belongs to a category. Each category could instead be a dictionary from where the compiler could find classes that are mentioned in the class source.
>
> This has worked wonders in Java (classes inside packages). This way classes' names can be repeated ad eternum without generating collisions or otherwise polluting excessively the name space.
>
> So for example:
>
> FAMIXAssociation subclass: #FAMIXInvocation
> instanceVariableNames: 'sender receiver receiverSourceCode signature candidates'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Famix-Core'
>
> Would be instead:
>
> Association subclass: #Invocation
> instanceVariableNames: 'sender receiver receiverSourceCode signature candidates'
> classVariableNames: ''
> poolDictionaries: ''
> category: #FamixCore
>
> Then the category would be an index in the SystemDictionary:
>
> SystemDictionary at: #FamixCore put: Category new.
>
> (SystemDictionary at: #FamixCore) belongingClassList add: #Invocation "this should be done automatically by the subclass: method above"
>
> (SystemDictionary at: #FamixCore) referencedClassList add: ... "classes that are referenced by classes belonging to category #FamixCore"
>
> What do you think?
>
> Cheers,
> Guillermo.
>
> Message: 1
> Date: Mon, 27 Sep 2010 22:00:33 +0200
> From: Tudor Girba <tudor.girba(a)gmail.com>
> Subject: [Moose-dev] Re: Class renaming in Moose Algos Graph
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Message-ID: <C912A83B-6BDC-4775-AC26-CE2DBC5540AE(a)gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Simon,
>
> These classes should be called MAlgo (or MAL ?). I started to do that a while ago, but apparently I forgot to commit this change.
>
> Cheers,
> Doru
>
>
> On 27 Sep 2010, at 19:42, Simon Denier wrote:
>
> >
> > On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
> >
> >> Please note that the MA* (with an uppercase $A) prefix is already
> >> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
> >> remember correctly they renamed their classes at some point a long
> >> time ago to avoid the conflict with Magritte.
> >
>
>
>
> --
> Saludos cordiales,
>
> Guillermo Schwarz
> Sun Certified Enterprise Architect
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Guys,
Why don't you do something more focused on the long term and don't you
change the Smalltalk compiler with namespaces?
I don't think it should be that hard since each class already belongs to a
category. Each category could instead be a dictionary from where the
compiler could find classes that are mentioned in the class source.
This has worked wonders in Java (classes inside packages). This way classes'
names can be repeated ad eternum without generating collisions or otherwise
polluting excessively the name space.
So for example:
FAMIXAssociation subclass: #FAMIXInvocation
instanceVariableNames: 'sender receiver receiverSourceCode signature
candidates'
classVariableNames: ''
poolDictionaries: ''
category: 'Famix-Core'
Would be instead:
Association subclass: #Invocation
instanceVariableNames: 'sender receiver receiverSourceCode signature
candidates'
classVariableNames: ''
poolDictionaries: ''
category: #FamixCore
Then the category would be an index in the SystemDictionary:
SystemDictionary at: #FamixCore put: Category new.
(SystemDictionary at: #FamixCore) belongingClassList add: #Invocation "this
should be done automatically by the subclass: method above"
(SystemDictionary at: #FamixCore) referencedClassList add: ... "classes that
are referenced by classes belonging to category #FamixCore"
What do you think?
Cheers,
Guillermo.
Message: 1
Date: Mon, 27 Sep 2010 22:00:33 +0200
From: Tudor Girba <tudor.girba(a)gmail.com>
Subject: [Moose-dev] Re: Class renaming in Moose Algos Graph
To: Moose-related development <moose-dev(a)iam.unibe.ch>
Message-ID: <C912A83B-6BDC-4775-AC26-CE2DBC5540AE(a)gmail.com>
Content-Type: text/plain; charset=us-ascii
Hi Simon,
These classes should be called MAlgo (or MAL ?). I started to do that a
while ago, but apparently I forgot to commit this change.
Cheers,
Doru
On 27 Sep 2010, at 19:42, Simon Denier wrote:
>
> On 27 sept. 2010, at 18:17, Lukas Renggli wrote:
>
>> Please note that the MA* (with an uppercase $A) prefix is already
>> taken by Magritte. Ma* (with a lowercase $a) is taken by Magma, if I
>> remember correctly they renamed their classes at some point a long
>> time ago to avoid the conflict with Magritte.
>
