Re: [Pharo-dev] editing the default window size of glamour inspector
by Nicolai Hess
2014-11-12 15:14 GMT+01:00 Clément Bera <bera.clement(a)gmail.com>:
> Hello,
>
> I would like for specific objects to change the default window size of the
> glamour inspector (Basically a bigger window will be opened by default for
> these objects). This is because I extended my inspectors to provide roassal
> visualization that are quite large.
>
> How can I do it ?
>
> For example I would like something like that:
>
> MyObject>>#gtInitialWindowExtent
> < gtInitialWindowExtent >
> ^ 800@1000
>
> Clement
>
>
I think this is not doable.
You can change the method with the inspector pragma to be called with the
context (inspector instance)
gtInspectorItemsIn: composite inContext: aGTInspector
<gtInspectorPresentationOrder: 30>
instead of
gtInspectorItemsIn: composite
<gtInspectorPresentationOrder: 30>
this way you have access to the glamour inspector. Unfortunately it does
not have any
window extent property.
Maybe we can move the initialExtent property from GLMBrowser up to
GLMPresentation?
That way it would be accessible and usable for this aGTInspector argument.
Nicolai
8 years, 10 months
Pharo and Categories Importer update
by Gustavo Santos
Hello,
I have noticed that the Category Importer was removed from Moose. I've been
using the Pharo Importer instead, but there are some information missing in
the model it generates (e.g., the parent package of a method). This
information is important for the project I'm working on (Orion).
So, I made commit of the missing code in order to make Orion tests pass
again. Does it make sense to commit on Moose to make PharoImporter work as
CategoriesImporter was working before?
Regards,
--
Gustavo Santos
8 years, 10 months
Extension in GT
by Alexandre Bergel
Hi Milton,
It would be great to have an export SVG and export HTML accessible from GT Inspector.
The starting point is the method GLMRoassal2Presentation >> defaultActions
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 years, 10 months
Menu in Roassal are not pretty
by Alexandre Bergel
This is a recurrent complain. We have to improve the menus…
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 years, 10 months
About RBCompiler
by Serge Stinckwich
I'm trying to port QuasiQuote package from Lukas Renggli to Pharo 3.0/4.0.
This package use the RBCompiler class from the AST-Compiler package
available here:
http://source.lukas-renggli.ch/helvetia
If I understand RBCompiler, this is a Compiler that use RB parser nodes.
I guess this is something that is no more relevant with the new Opal compiler ?
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
8 years, 10 months
Kiviat support in Roassal
by Alexandre Bergel
Hi!
Pierre just finished a first version of Kiviat in Roassal. Here are some example:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
b := RTKiviatBuilder new.
b objects: RTAbstractCircleLayout withAllSubclasses.
n := RTMultiLinearColorForIdentity new objects: (b objects).
b shape circle color: [ :value | n rtValue: value named]; size: 10.
b addMetric: #numberOfLinesOfCode.
b addMetric: #numberOfMethods.
b addMetric: #numberOfVariables.
b activatePolygons.
b build.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It would be great to have feedback on this!
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 years, 10 months
Caveat Example added
by Alexandre Bergel
Hi!
I migrated some of Pierre's example into the GT-based browser:
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 years, 10 months
Re: Why extra configurations for GT
by Stephan Eggermont
Doru wrote:
>On Fri, Nov 21, 2014 at 11:39 AM, Stephan Eggermont <[hidden email]> wrote:
>>Why are there extra configurations for GT?
>
>Because we will go away from groups and because we needed to have the tools loadable individually.
Why do you want to go away from groups?
Tools can be loaded individually with groups.
>I'm afraid that leads to duplication of effort,
>
>Why?
Because there is already lots of duplication in those separate configurations.
>>and introduces lots of problems.
>
>What kind of problems?
missing updates. Basically no DRY
>>Moose was nearly loading in Pharo 4,
>>the only thing that went wrong was the loading of fonts.
>
>Where is the difference now?
missing groups
Stephan
8 years, 10 months
ConfigurationOfGlamour broken, needs CoreExtras group
by Stephan Eggermont
The removal of the CoreExtras group is a change that needs to propagate
to all configurations using Glamour (or be undone). It is a change to the
public API. It currently breaks loading Moose in Pharo 4
Stephan
8 years, 10 months
