Hi everyone,
There is a behavior of event TRMouseClick that seems anormal to me.
For example I can't define a TRMouseClick on an element before it appears
in a view via a little animation, because if the element pass by my mouse
cursor, it will freeze. It seems that the element detect that the mouse
cursor is on him and might click on him.
That behavior would be normal with TRMouseEnter for exemple but a click
should be just a click right ?
Pierre Chanson
Hi Alex,
Could you please review the code in RTPNGExporter? We still get a little
problem when exporting because it seems that there is a bit of clipping
happening on the bottom and to the right.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Hi!
Nelson is an excellent student from Bolivia. We met Nelson at the summer school (sponsored by ESUG) that we organized.
Nelson would like to write an MSE exporter for Ruby. Analyzing Ruby applications in Moose is indeed important.
Nelson, as a starting point how how to produce MSE file, you can have a look at
- http://www.themoosebook.org/bookhttp://www.themoosebook.org/book/externals/import-export/mse
- Try out with .mse file example. You can easily generate one by importing Pharo code in Moose (http://www.themoosebook.org/book/externals/import-export/smalltalk) and export it by right clicking on a model
Ask for help in the mailing list. People are waiting for your tool :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello,
Is it possible to avoid to open a new pane when browsing from a specialized inspector tab?
I have a specialized inspector tab with a table. I want to be able to select a raw and get the value by calling #selection on the presentation but I don't want a new pane to be opened on this selection.
By using noSelectionTransmission, there is no new pane opened but no selection available.
Christophe.
There is a DNU when browsing Roassal example in last MOOSE 5.0 version
on CI server:
GLMPager>>shouldDisplayPresentationCreatedBy:
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
Dory wrote:
>What's left?
- a few small ones
- next interesting ones are Glamour, PetitParser and Roassal2.
- adding a test version to C-O-Moose with the stable versions of all dependencies
- if everything works, make a snapshot so we know what exact versions were loaded...
Name: ConfigurationOfPastell-StephanEggermont.12
Author: StephanEggermont
Time: 10 December 2014, 4:01:06.450525 pm
UUID: 7fb6a243-6514-4a6e-91ec-7930144c0e7d
Ancestors: ConfigurationOfPastell-DiegoLont.11
new stable version, depend on stable XMLParser
That's it for me for today.
CollectionsExtensions is referred to in both ConfigurationOfMooseAlgos
and ConfigurationOfGlamour. Semantically it is part of MooseAlgos
The dependencies in baseline25 are not so nicely written.
I assume the test packages depend on the packages they test.
Moose-Algos-GraphObjectTraverser has no test package
Name: ConfigurationOfMooseAlgos-StephanEggermont.52
Author: StephanEggermont
Time: 10 December 2014, 3:32:57.214482 pm
UUID: 3dca6af0-2cf6-428b-be2b-ec8236bab163
Ancestors: ConfigurationOfMooseAlgos-TudorGirba.51
Created a stable version
Stable version, can't commit
Name: ConfigurationOfAnnouncerCentricDebugger-StephanEggermont.9
Author: StephanEggermont
Time: 10 December 2014, 10:44:39.252925 am
UUID: 091e7693-0cf8-4bf1-8250-5b6c3a968589
Ancestors: ConfigurationOfAnnouncerCentricDebugger-AndreiChis.8
made a stable version
Andrei wrote:
>We just need numbered versions for the configurations that are linked to pharo:
>
>ConfigurationOfGlamourCore
>ConfigurationOfGTInspectorCore
>ConfigurationOfGTPlaygroundCore
>ConfigurationOfRubric
>
>I permanently update these configurations every time we integrate into pharo.
>For the rest there is no problem to use #stable
Ok, let's do that.
Stephan
Doru wrote:
>That would not work well now because of a conflict with merging in Pharo 4
>which requires concrete version numbers for now.
Ahh, didn't know that. I assume that is something that will be resolved
soonish?
>So, I suggest we leave GToolkit related configurations to be as they are
>and we will depend on the #stable of GToolkit. This should be fine given
>that we do not expect much changes in Pharo 3, and we will have to
>change the way we approach to overall process from Pharo 4 on.
>
>Would that be Ok?
Let me think and check out loud.
There is lots of development in GToolkit, so it will definitely break
very fast after release, and the developers also have time and access
to patch configurations, so they can fix problems quickly. Not nice,
but no deal breaker.
ConfigurationOfGToolkit already has different baselines for Pharo 3 and 4
development: spec
<symbolicVersion: #'development'>
spec for: #'common' version: '0.6-baseline'.
spec for: #'pharo3.x' version: '0.18-baseline'.
spec for: #'pharo4.x' version: '0.17-baseline'
so an alternative could be to also have different versions of the other
GT configurations. The Pharo3 one using symbolic names, the 4 version not.
The GToolkit related configurations include Rubric, DeepTraverser and NewDebugger
so the change scope is limited.
I assume ConfigurationOfGlamour can use symbolic dependencies
to roassal2 and glamour core?
I'd prefer adding a symbolic version, but can live with the numbered version
in GToolkit related configurations
Stephan
Hi.
Is is possible to modify to which object you are transmitted when you click on a Roassal2 view in GTInspector? I’ve seen that you can use #send: of glamour representation, but my question is: can it be done if I’m just scripting the thing in the playground? For example when I click in spectrograph node it opens a 2 elements array, and I need only one of them.
Uko
Stable is a newer version than development, let's see what happens...
Name: ConfigurationOfBitmapCharacterSet-StephanEggermont.9
Author: StephanEggermont
Time: 10 December 2014, 10:52:10.812126 am
UUID: 26927de9-f959-4410-bdc1-3d0933bb9985
Ancestors: ConfigurationOfBitmapCharacterSet-monty.8
Bugfix: development should not refer to an old version, replaced by baseline
Andrei wrote:
>I added a stable version for the following configurations:
>
>ConfigurationOfGlamourCore
>ConfigurationOfGlamour
>ConfigurationOfGTSpotter
>ConfigurationOfGTInspectorCore
>ConfigurationOfGTInspector
>ConfigurationOfGTPlaygroundCore
>ConfigurationOfGTPlayground
>ConfigurationOfRubric
>
>I'll continue to add stable versions for the remaining configurations that belong to GToolkit.
Thank you. In the version you declare as stable,
the dependencies should not be to numbered versions, so could you please replace e.g. in
ConfigurationOfGlamourCore>>version304: spec
<version: '3.0.4' imports: #('3.0-baseline' )>
spec for: #'common' do: [
spec blessing: #'stable'.
spec description: 'version 3.0.4'.
spec author: 'AndreiChis'.
spec timestamp: '12/09/2014 12:08'.
spec
package: 'Glamour-Announcements' with: 'Glamour-Announcements-AndreiChis.8';
package: 'Glamour-Helpers' with: 'Glamour-Helpers-AndreiChis.36';
...
package: 'Glamour-Tests-Rubric' with: 'Glamour-Tests-Rubric-AndreiChis.14';
package: 'Glamour-Tests-Resources' with: 'Glamour-Tests-Resources-AndreiChis.3'.
spec
project: 'Rubric' with: '1.2.5' ].
the reference to Rubric 1.2.5 to #stable (as long as Rubric only defines #stable and #development)
Stephan
Hi!
We were thinking that it would be great to have the url open package Sean did some weeks ago into Moose. We would like to have it, accessible from GTInspector, to open a HTML page of a visualization.
Shall we package it in Roassal?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello
When I install Roassal2 from the ConfigurationBrowser in a fresh clean
Pharo 3.0 image, and select Roassal -> Roassal examples GT, a MNU is raised
(see the attached screenshot)
Is this known issue?
Any fix?
Cheers,
Hernán
ConfigurationOfXMLWriter can be used as is with #stable
ConfigurationOfXMLParser baseline now uses #stable.
These configurations really should be combined
and use groups, or be made independent.
Stephan
Hi!
How the Moose image is built? From which version of Pharo? The last version of Pharo 4.0?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.