Moose-dev

moose-dev@list.inf.unibe.ch

6630 discussions

by Cyril Ferlicot

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 1 month

Improvement on DistributionMap

by Anne Etien

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

7 years, 2 months

Glamour: Raw list selection?

by Sean P. DeNigris

I have a list presentation that modifies the selection before transmitting: a list … send: [ :version | [ db backupVersion: version ] on: Error do: [ :e | e ] ] This makes sense for consumption by other presentations, but I just discovered the need internally-to-the-list to access the raw selection (before the sendBlock is applied). Is that possible? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 2 months

Passing context class with GTSpotter

by Peter Uhnák

Hi, I'm extending Spotter and wonder how I can achieve the following. I have some domain model, for the sake of example let's imagine Item" and "Container" classes; where "Container" can contain other Items or Containers. Then I have a custom Spotter wrapper class that shows the initial Spotter cadidates and can perform something with the spotted objects. Object subclass: #MySpotterModel slots: { #container. #something }. MySpotterModel>>doSomethingWith: item something doSomethingTo: item MySpotterModel>>spotterContentFor: aStep <spotterOrder: 10> ^ aStep listProcessor title: 'Items'; candidatesLimit: Float infinity; allCandidates: [ container items ]; actLogic: [ :item | self doSomethingWith: item. aStep exit ]; matchSubstring So far so good. Now the problem is, that I would like to "dive" (right arrow) into a container further, so there would be (notice that I am already duplicating behavior) MySpotterModel>>spotterContentFor: aStep <spotterOrder: 10> ^ aStep listProcessor title: 'Items'; candidatesLimit: Float infinity; allCandidates: [ self items ]; actLogic: [ :item | "self doSomethingWith: item. "<<<<<<<------------ aStep exit ]; matchSubstring So my question is ... how can I "pass along" a custom instance? Thanks, Peter

7 years, 2 months

Management of #queryAll{Direction}Associations (complete one)

by Cyril Ferlicot

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 2 months

RTExampleFactory is missing sourceClass:

by Alexandre Bergel

Hi! How can I update GTExample? Why not having a "GToolkit update” world menu entry, somewhere? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

7 years, 2 months

Cannot update GLMTabulator containing list with Separators

by Peter Uhnák

Hi, apparently it is not possible to update a GLMTabulator if it contains a list pane with separators. Tested in P6 & P7. ``` data := { { #one. #two. #three } asOrderedCollection. { #alpha. #beta } asOrderedCollection } asOrderedCollection. browser := GLMTabulator new. browser column: #list; column: #actions. browser transmit to: #list; andShow: [ :a | a fastList withSeparators ]. browser transmit to: #actions; andShow: [ :a | a actionList act: [ :actionList | data last add: #dynamic. browser update ] entitled: 'Add Item'; act: [ :actionList | data last remove: #dynamic ifAbsent: [ ]. browser update ] entitled: 'Remove Item'. ]. browser openOn: data. ``` [image: Inline image 1] Thanks, Peter

7 years, 2 months

GLMTabulator buttons

by Peter Uhnák

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

7 years, 2 months

Inspector Presentation?

by Sean P. DeNigris

I've found the following idiom (or parts of it) to be repeatedly useful: browser transmit ... andShow: [ :a :b | a finder show: [ :b :object | object gtInspectorPresentationsIn: b inContext: GTInspector new ] ] I wonder if it's worth reifying into the DSL. I first thought `a inspector`, but it seems Object already implements it to open an actual... inspector ;) ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 2 months

Moose Editor: Can We Handle Errors More Gracefully

by Sean P. DeNigris

While protoyping a Glamour browser in the editor, it seemed that once I got an error, I was no longer able to "Go" and have the browser appear in the top pane. I had to close the editor and open a new one. This was an unsatisfying workflow. Is there a workaround? If not, could we wrap these inevitable errors so they don't take down the tool? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev