Moose-dev October 2011

moose-dev@list.inf.unibe.ch

29 participants
175 discussions

Issue 720 in moose-technology: Classic Coder should highlight the extension categories
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-GlamorousToolkit New issue 720 by tudor.gi...(a)gmail.com: Classic Coder should highlight the extension categories http://code.google.com/p/moose-technology/issues/detail?id=720 Currently, only classes and methods are shown as extensions using gray. Categories should be grayed out as well.

1 2

Issue 640 in moose-technology: Get the axis labels in a lineDiagram
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: andreho...(a)gmail.com Labels: Type-Defect Priority-Medium Component-EyeSee New issue 640 by andreho...(a)gmail.com: Get the axis labels in a lineDiagram http://code.google.com/p/moose-technology/issues/detail?id=640 Get the axis labels in a lineDiagram in not working. See example below: | diag factory | factory := ESDummyFactory new. factory yValues: #(22 25 13 16 24 28 35 24 32 24 46 12). factory identifiers: #('January' 'February' 'March' 'April' 'Mai' 'June' 'July' 'August' 'September' 'October' 'November' 'December'). diag := ESDiagramRenderer new. (diag lineDiagram) y: #yValue; width: 500; height: 400; lineWidth: 5; defaultFontSize: 12; identifier: #identifier; labels: [:each | each]; defaultColor: Color blue; yAxisLabel: 'Clients'; regularAxis; deviationValue: 22; deviationDescription: 'avg 2006'; models: factory buildDummies. "startLineAtZero;" ^ diag open

1 2

Issue 637 in moose-technology: VerveineJ should show an invocation to the default constructor
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 637 by tu...(a)tudorgirba.com: VerveineJ should show an invocation to the default constructor http://code.google.com/p/moose-technology/issues/detail?id=637 A call to the default constructor should be modeled like: - create a stub constructor in the target class - create an invocation to the constructor See the attached class for a sample. Attachments: DefaultConstructor.java 184 bytes

1 6

Issue 636 in moose-technology: VerveineJ should set hasClassScope
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 636 by tu...(a)tudorgirba.com: VerveineJ should set hasClassScope http://code.google.com/p/moose-technology/issues/detail?id=636 Static fields or methods should be marked with hasClassScope=true: public static int attributeWithClassScope; public static void methodWithClassScope() {} See the attached sample class. Attachments: ClassScope.java 179 bytes

1 3

Issue 734 in moose-technology: VerveineJ does not export parameters for stub methods
by moose-technology＠googlecode.com 30 Nov '12

30 Nov '12

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 734 by tu...(a)tudorgirba.com: VerveineJ does not export parameters for stub methods http://code.google.com/p/moose-technology/issues/detail?id=734 If we analyze this code, the print method will appear without parameters. public class NoParametersInStubMethods { public void invoking() { System.out.print("aString"); } }

2 2

Issue 708 in moose-technology: Fame should accept comments both for properties and for meta descriptions
by moose-technology＠googlecode.com 25 Nov '12

25 Nov '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-MooseCore Milestone-4.6 New issue 708 by tudor.gi...(a)gmail.com: Fame should accept comments both for properties and for meta descriptions http://code.google.com/p/moose-technology/issues/detail?id=708 Currently, the MSEComment: is used to define comments of a property. SomeEntity>>someProperty <MSEProperty: ...> <MSEComment: 'comment'> This is used by the MetaBrowser but not by Fame. At the very least, we should add a means to add MSEComment: to the class side for the overall class.

1 5

Issue 650 in moose-technology: Mondrian multiple selection uses a broken metaphor
by moose-technology＠googlecode.com 14 Oct '12

14 Oct '12

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.

1 9

Re: Issue 396 in moose-technology: Mondrian should provide teh start and end nodes in the edge action
by moose-technology＠googlecode.com 03 Oct '12

03 Oct '12

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

1 1

Issue 698 in moose-technology: Mondrian does not properly raise MOElementSelection
by moose-technology＠googlecode.com 03 Oct '12

03 Oct '12

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 ].

4 15

Re: Issue 113 in moose-technology: Lazy edges in Mondrian
by moose-technology＠googlecode.com 03 Oct '12

03 Oct '12

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?

2 5

← Newer
1
2
3
4
5
6
7
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev October 2011