Moose-dev June 2012

moose-dev@list.inf.unibe.ch

20 participants
112 discussions

Issue 746 in moose-technology: VerveineJ should create parameters for methods with different signatures

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.6 New issue 746 by tu...(a)tudorgirba.com: VerveineJ should create parameters for methods with different signatures http://code.google.com/p/moose-technology/issues/detail?id=746 In some cases, calls to external libraries get reified as methods with proper signatures, but without parameters. I am trying to reproduce this using the following example (in ad_hoc/MultipleSignatures.java): package ad_hoc; import java.io.PrintWriter; import java.io.StringWriter; public class MultipleSignatures { public void callToRegularPrintStackTrace(Throwable t) { t.printStackTrace() } public void callToPrintStackTraceWithParam(Throwable t) { t.printStackTrace(new PrintWriter(new StringWriter())) } } I encountered a similar code in a case study. However, in this case, I cannot even get the parser to recognize both printStackTrace calls.

12 years, 5 months

Issue 769 in moose-technology: Glamour should support drag and drop

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Milestone-4.6 Component-Glamour New issue 769 by tudor.gi...(a)gmail.com: Glamour should support drag and drop http://code.google.com/p/moose-technology/issues/detail?id=769 Something like this: a list allowItemDrag: [:item :list | ... ]; itemDrag: [:item :list | ... ] a list allowDropOnItem: [:draggedObject :targetItem :list | ... ]; dropOnItem: [:draggedObject :targetItem :list | ... ]

12 years, 5 months

Issue 708 in moose-technology: Fame should accept comments both for properties and for meta descriptions

by moose-technology＠googlecode.com

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.

12 years, 5 months

Issue 799 in moose-technology: Editing code in Glamour must be faster

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: esteba...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7 New issue 799 by tudor.gi...(a)gmail.com: Editing code in Glamour must be faster http://code.google.com/p/moose-technology/issues/detail?id=799 Launch the following browser, and then try to type more code. It is dead slow. Using the same fragment in the workspace is fast. This means that we are probably using the PluggableTextMorph in a wrong way. The problem appeared since Pharo 1.4. GLMWrapper new show: [:a | a text ]; openOn: 'GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen. GLMWatcherWindow uniqueInstance toggleOpen.'

12 years, 5 months

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.

12 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

12 years, 7 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 ].

12 years, 7 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?

12 years, 7 months

adding scroll bars to Roassal Visualization

by Usman Bhatti

Hello, How to we add horizontal and vertical scroll bars to a Roassal visualization. I browsed through some examples but could not find one with these. tx. usman

12 years, 7 months

Issue 792 in moose-technology: Mondrian - broken popupText:

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 792 by google....(a)ben.coman.com.au: Mondrian - broken popupText: http://code.google.com/p/moose-technology/issues/detail?id=792 I have isolated what I assume is an issue introduced in ConfigurationOfMondrian-AlexandreBergel.332 with #popupText: Test Case to execute in Mondrian Easel... view interaction popupText: [ :es | 'popupText works']. view shape label. view node: 'node value'. With a freshly unzipped Moose_Suite_4_6, hovering over the node displays a blue box that says 'popupText works' Using Monticello Browser to load ConfigurationOfMondrian-AlexandreBergel.331 then doing '(Smalltalk at: #ConfigurationOfMondrian) project lastVersion load' has the same behaviour. With Monticello Browser, loading ConfigurationOfMondrian-AlexandreBergel.332 then doing '(Smalltalk at: #ConfigurationOfMondrian) project lastVersion load' hovering over the node displays a white box that says 'node value' This behaviour persists through to current ConfigurationOfMondrian-AlexandreBergel.348 The comment on 332 is: 2.147 : Pharo ground is seriously shaking those days... popupText: does not use the Pharo popup, it instead uses popupView: Platform: Windows 7

12 years, 8 months

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev June 2012