Moose-dev March 2012

moose-dev@list.inf.unibe.ch

32 participants
132 discussions

Issue 650 in moose-technology: Mondrian multiple selection uses a broken metaphor

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.5 New issue 650 by tu...(a)tudorgirba.com: Mondrian multiple selection uses a broken metaphor http://code.google.com/p/moose-technology/issues/detail?id=650 The multiple selection mechanism is confusing because you have to release the mouse to start selecting. It should be disabled until it works properly.

11 years, 6 months

Re: Issue 396 in moose-technology: Mondrian should provide teh start and end nodes in the edge action

by moose-technology＠googlecode.com

Updates: Cc: tudor.girba Comment #1 on issue 396 by alexandre.bergel: Mondrian should provide teh start and end nodes in the edge action http://code.google.com/p/moose-technology/issues/detail?id=396 I started to work on this (testHandlerOnEdge). However, I am unsure for few things. view interaction on: MOMouseDown do: [ :v | ... ] What v is supposed to be? The announcement or the value on which one has clicked? It has to be the value I believe. However, it may brake already existing code. We could leave it like this, and introduce on:withValueDo: What do you think? Cheers, Alexandre

11 years, 6 months

Issue 698 in moose-technology: Mondrian does not properly raise MOElementSelection

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-High Component-Mondrian Milestone-4.6 New issue 698 by tudor.gi...(a)gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698 When in Glamour, often when selecting a Mondrian element does not populate the selection because the MOCanvas does not raise MOElementSelection. The reason for this seems to be a race condition due to changes in the announcement framework. In the new announcement framework from Pharo 1.3, the order of announcements is not guaranteed. The issue seems to be due to the logic of the announcement: MOCanvas>>mouseUp: .. (lastEnteredGraphElement isNil not and: [ (lastEnteredGraphElement class ~~ MORoot and: [ lastEnteredGraphElement isNotSelected ])]) ifTrue: [ selectionEvent := MOElementSelection event: anEvent on: lastEnteredGraphElement. anEvent commandKeyPressed ifTrue: [ selectionEvent setAsMultiple ]. self announce: selectionEvent. anEvent wasHandled: true. ^ self ]. Sometimes, "lastEnteredGraphElement isNotSelected" returns false because somehow the element gets selected beforehand. This is most likely related to the fact that the selection of a node actually happens by handling the same MOElementSelection announcement: MOCanvas>>announce: anAnnouncement ... anAnnouncement element isNil ifFalse: [ anAnnouncement element announcer announce: anAnnouncement ]. self announcer announce: anAnnouncement. MOViewRenderer>>setUsefulHandlersForNodes ... self interaction on: MOElementSelection do: [:ann | ann isUnique ifTrue: [ self root allSelectedNodes do: [ :node | node deselect; announce: (MOElementDeselection new) ] ]. ann element select. self updateWindow ].

11 years, 6 months

Re: Issue 113 in moose-technology: Lazy edges in Mondrian

by moose-technology＠googlecode.com

Updates: Labels: -Milestone-4.2 Comment #5 on issue 113 by tudor.gi...(a)gmail.com: Lazy edges in Mondrian http://code.google.com/p/moose-technology/issues/detail?id=113 Should we postpone this one until later?

11 years, 6 months

Issue 701 in moose-technology: Cut and Paste do not update a Glamour Port

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour New issue 701 by alexandr...(a)gmail.com: Cut and Paste do not update a Glamour Port http://code.google.com/p/moose-technology/issues/detail?id=701 Email snippets: Regarding copy paste, indeed it seems that pasting a text does not update the port. Please open a ticket. ------- I found another strange behavior, likely to be a bug. Try: -=-=-=-=-=-= | browser | browser := GLMFinder new. browser text act: [:prez :v | prez text inspect ] on: $i entitled: 'Inspect'. browser openOn: 'hello world' -=-=-=-=-=-= If you type something and press cmd-i then you open an inspector on what you have typed. Now, do a cut and paste in the textpane, and press cmd-i. You have an inspector on 'hello world', no matter what you have cut&pasted.

11 years, 9 months

Issue 785 in moose-technology: inFamix don't export FAMIXLocalVariable>>parentBehaviouralEntity

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 785 by fabrizio...(a)gmail.com: inFamix don't export FAMIXLocalVariable>>parentBehaviouralEntity http://code.google.com/p/moose-technology/issues/detail?id=785 FAMIXLocalVariable entities exported with inFamix are not associated with the behavioural entity they are belong to.

11 years, 10 months

Issue 501 in moose-technology: Cache independence

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 501 by alexandr...(a)gmail.com: Cache independence http://code.google.com/p/moose-technology/issues/detail?id=501 The core of Mondrian is not independent of the cache implementation. The logic of Mondrian rely on the cache to implement its semantics. This is obviously wrong. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= bounds "Answer the bounds of the receiver." "the bounds is has an absolute origin" "Note that the bounds computed above, may have (and it is likely to) a different origin. The reason is that the layout is in charge to position the nodes properly" | basicBounds | boundsCache ifNotNil: [ ^ boundsCache ]. "We check if the shape if present" self shapeBoundsAt: self shape ifPresent: [ :b | ^ boundsCache := b ]. basicBounds := self shape computeBoundsFor: self. self shapeBoundsAt: self shape put: basicBounds. ^ boundsCache := basicBounds -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= translateAbsoluteCacheBy: aPoint absoluteBoundsCache ifNil: [ ^ self ]. absoluteBoundsCache := absoluteBoundsCache translateBy: aPoint -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Thanks to Santiago Vidal for pointing this out!

11 years, 10 months

Issue 503 in moose-technology: Abstract classes and Hapao

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: vhane...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Spy New issue 503 by alexandr...(a)gmail.com: Abstract classes and Hapao http://code.google.com/p/moose-technology/issues/detail?id=503 Gaëtan le Brun suggested to remove abstract classes before running the test in Hapao. This makes sense

11 years, 11 months

Issue 601 in moose-technology: Covered methods and tests

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Hapao New issue 601 by alexandr...(a)gmail.com: Covered methods and tests http://code.google.com/p/moose-technology/issues/detail?id=601 It would be good to see what are the tests that _indirectly_ tests a methods. Thanks Laurent & Patrick

11 years, 11 months

Reviewing Fuel export/import utility

by Martin Dias

Hello, I'm looking to improve current implementation, and maybe you can help me. The current procedure is based in a custom serialization of each MooseElement. It's inspired on MSE, I describe this with the following pseudo-code: serialize: aMooseElement (MooseModel meta descriptionOf: aMooseElement class) allAttributes do: [ :anAttribute | | values | values := anAttribute getFrom: aMooseElement. (self shouldIgnore: anAttribute withAll: values) ifFalse: [ self serialize: anAttribute withAll: values ] ]. where: shouldIgnore: anAttribute withAll: values ^ values isEmpty or: [ anAttribute isDerived or: [ anAttribute type == FM3MetaDescription boolean and: [ values size == 1 and: [ values first == false ]]]] The advantage of serializing the MooseElements in this way (and not just as a normal object) is to avoid storing unnecessary stuff that aMooseElement references. It's a disadvantage using FM3PropertyDescription>>getFrom: (and then to import, FM3PropertyDescription>>setOn:values:) which ends sending #perform: of the corresponding accessor selector. It'd be better to use #instVarAt: (and #instVarAt:put:) as Fuel normally does. I hope I've been clear enough to explain up to this point. Now my question: Do you think Fuel can do something on each MooseElement like - clean up some unnecessary references - declare some instance variables as transient - if it's not good idea to modify the elements, create a method like MooseElement>>copyWithoutDerivedValues, and so actually serialize such copy instead of the original element - any other ??? and thus, serialize the MooseElements as normal Fuel objects, removing the custom procedure. I'll be happy to receive some help from Moose and Fame experts! Thanks in advance. Martín

11 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev March 2012