> Begin forwarded message:
>
> From: Sven Van Caekenberghe <sven(a)stfx.eu>
> Subject: [Pharo-users] [ ANN ] Pharo Days 2016
> Date: December 9, 2015 at 9:52:09 AM EST
> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Pharo Business <pharo-business(a)lists.pharo.org>
> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
>
> Dear fellow Pharoers,
>
> Mark your calendars: on Thursday March 31 & Friday April 1 we are organising the Pharo Days 2016. This year we moved the location to Namur, Belgium, just a bit south of Brussels, at the very beautiful location of the ‘Cercle de Wallonie’ overlooking the river Meuse.
>
> We’ll update the following page moving forward.
>
> https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf
>
> You can ask questions on any of the Pharo mailing lists or you can email the Pharo Board.
>
> Let's make this another success, together ! We hope to see as many of you as possible.
>
>
--
www.tudorgirba.com
"We are all great at making mistakes."
Synectique is openning the source code for a C/C++ parser based on
Eclipse CDT.
https://github.com/Synectique/VerveineC-Cpp.git
The parser was developed as an Eclipse (Mars release) plugin and is
under MIT licence.
nicolas
--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod
Hello,
Is there a way to set a default selection to a list presentation? so that
when I open the browser, the morphic list has already a value selected.
I tried that:
|tmpBrowser|
tmpBrowser := GLMTabulator new.
tmpBrowser row: #list.
tmpBrowser transmit to: #list; andShow: [:a |
a list
display: [:input | input];
selection: #a;
yourself
].
tmpBrowser openOn: #( b c d v a d f r).
but the list still open with nothing selected
Hoi,
What is the best way for an object to delegate one or more GTInspector
views to other objects?
I have been using a pattern like this:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
but I am wondering whether there is a better way, and also whether this
method is valid (I've occasionally seen odd behavior, like Inspector panes
disappearing after I "Refresh", and I wonder if I could be somehow
confusing the model or if this is not relevant.)
also: Supposing this pattern is valid, is there an easy way to override the
title of the view(s) added by otherObject?
Hi,
Currently Moose-Query works with Traits.
There is :
- TDependencyQueries containing all the query system and the common
queries such as #queryIncomingAccesses
- TOODependencyQueries using TDependencyQueries and adding the method
specific to OO entities (mostly inheritance queries)
The users of TDependencyQueries are:
- TOODependencyQueries
- FAMIXAnnotationInstance
- FAMIXAnnotationInstanceAttribute
- FAMIXSourceAnchor
The users of TOODependencyQueries are:
- FAMIXNamedEntity
I think it would make sense to move TDependencyQueries to FAMIXEntity.
FAMIXEntity has all the API needed to the queries and it would help
with the consistancy. For example I think that all famix entities
should be able to answer to "queryAllIncomingAssociations". It would
felp making more generic tools.
What do you think? Does that bother someone?
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
I find how to easily do one Distribution map from elements.
However, as you can see, it is not very beautiful.
- Is there an easy way to get legend on distribution map? Here each color corresponds to an author, but if I don’t say it to you you can’t invent it.
- the labels are too long, there are the result of element printString and not of element mooseName. How can I change that?
- I would also like to be able to inspect each element when clicking on it. But once again, since DistributionMap doesn’t inherit from any Roassal element, I don’t know how to do it.
Can anyone help me?
Thanks in advance.
Anne
Hi!
Sorry for my previous incomplete mail. I missclicked. Here is the full one:
I have some improvements I would like to make to Moose query and I
would like your approuval.
First. Currently there is:
- #queryAllOutgoing and #queryAllOutgoingAssociations to query all the
outgoing associations of the receiver
- #queryAllIncoming and #queryAllIncomingAssociations to query all the
incoming associations of the receiver
#queryAll{Direction} is based on the meta-model properties while
#queryAll{Direction}Associations seems to be more empirical.
See:
queryAllOutgoingAssociations
^ self queryStaticOutgoingAssociations
addAll: self queryAllOutgoingInvocations;
yourself
I propose two changes:
- Remove the empirical implementation to use only the one based on the
meta-model
- Deprecate #queryAllIncoming and #queryAllOutgoing. I think
#queryAllIncomingAssociations is a better name, but I can change my
mine if you have a different opinion on that.
Second. To query all the in/out associations with the method based on
the meta-models, there is the use of "FAMIXAssociation
withAllSubclassesDo:" to iterate on the associations and do the
queries for all of them.
I have three problems with that:
- This is not efficient. If an entity can have only 2 incoming
associations it will still try the queries for all the associations in
the image
- This has a role in the circular dependency between FAMIX-Core and
Moose-Query packages because we reference FAMIXAssociation
- If one day we create another project from FAME to represent
something that is not a software model, we will maybe not have
FAMIXAssociation but we might still have associations. And Moose-Query
could still be useful on this project.
I propose to add to TEntityMetaLevelDependency two methods:
allOutgoingAssociationTypes
^ (self allChildrenTypes flatCollectAsSet: #outgoingAssociationTypes)
addAll: self outgoingAssociationTypes;
yourself
and
allIncomingAssociationTypes
^ (self allChildrenTypes flatCollectAsSet: #incomingAssociationTypes)
addAll: self incomingAssociationTypes;
yourself
Thus the entities will be able to return the associations they and
their children can have.
Then we can replace "FAMIXAssociation withAllSubclassesDo:" by "(self
strategy allAssociationTypesFor: anEntity)
do:" where the strategy is a MooseQuery{Direction}DirectionStrategy
that will call either #allIncomingAssociationTypes or
#allOutgoingAssociationTypes.
I have an image with all those changes and all the tests of
Moose-Query and Moose-Chef are green.
I am waiting your opinion on this changes.
Have a nice day.
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi!
How can I update GTExample?
Why not having a "GToolkit update” world menu entry, somewhere?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I went through the GLM examples and the chapter (
http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Glamour.pdf
) however none of them mention any of the following.
Is it possible to change the width of an action button? It seems that the
width is fixed.
[image: Inline image 1]
Likewise is it possible to change the layout, so the buttons are on top of
each other and not side-by-side?
Finally it seems that setting icons does not work; tested in Pharo 6 and
Pharo 7: (screenshot above). Maybe it works only for the toolbar icons?
browser := GLMTabulator new.
browser column: #one.
browser transmit to: #one; andShow: [ :a |
a actionList
act: [:entity | entity inspect ] iconName: #glamorousInspect entitled:
'Longer Button Label...';
act: [:entity | entity explore ] icon: #glamorousOpen asIcon entitled:
'Explore'].
browser openOn: 42.
Any pointers appreciated,
Peter