Moose-dev September 2012

moose-dev@list.inf.unibe.ch

25 participants
124 discussions

Issue 769 in moose-technology: Glamour should support drag and drop
by moose-technology＠googlecode.com 25 Nov '12

25 Nov '12

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

5 12

Issue 809 in moose-technology: Glamour selection should happen through an action
by moose-technology＠googlecode.com 25 Nov '12

25 Nov '12

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.7 New issue 809 by tudor.gi...(a)gmail.com: Glamour selection should happen through an action http://code.google.com/p/moose-technology/issues/detail?id=809 Right now, selecting an item in the user interface will directly populate the #selection port. However, this is less than ideal because it does not allow the developer to intervene in this process. One possibility would be to introduce a selectionAction that is triggered by the ui, and to provide the default behavior is simply setting the #selection port.

1 1

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 799 in moose-technology: Editing code in Glamour must be faster
by moose-technology＠googlecode.com 16 Nov '12

16 Nov '12

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

1 10

Issue 836 in moose-technology: Bug in GLMMorphicBrowserRenderer
by moose-technology＠googlecode.com 15 Oct '12

15 Oct '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 836 by julioari...(a)gmail.com: Bug in GLMMorphicBrowserRenderer http://code.google.com/p/moose-technology/issues/detail?id=836 Hello, in the class GLMMorphicBrowserRenderer I had a out of bound problem the first time that a model was charged (click on model). I changed the code of the render method (when activeEntity message on aBrowser object is sent)as follow: aBrowser activeEntity: ((aBrowser panes at: (ann pageIndex max: aBrowser panes size)) port: #entity) value ]. It was ok for me. So, I suggest this change to the Moose Developers. Hugs, Julio Ariel Hurtado

3 8

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

ROMenuActivable on raw graphic elements
by Ben Coman 07 Oct '12

07 Oct '12

I have split this post into two parts since I think any follow up will form two distinct threads. As I am developing using Roassal, I find it useful to Explore the graphic elements from a context menu. To demonstrate I have adapted ROExample>>linesOn: "-------------" "-------------" menu := (ROMenuActivable new) item: 'Explore graphic element' action: [ :model | (rawView elementFromModel: model) explore ]. node1 := ROLabel elementOn: 'node1'. node2 := ROLabel elementOn: 'node2'. node1 @ RODraggable @ menu. node2 @ RODraggable @ menu. "uncomment next three lines for Part Two edge := ROEdge lineFrom: node1 to: node2. edge + (ROLine red). rawView add: edge. " rawView add: node1; add: node2. ROHorizontalLineLayout on: (Array with: node1 with: node2). "-------------" "-------------" Is there (or can there be added) a way to access the graphic element more directly? Something like one of the following two lines... item: 'Explore graphic element' action: [ :model :element | element explore ]. item: 'Explore graphic element' rawAction: [ :element | element explore ].

2 5

Issue 835 in moose-technology: MooseGroup symbolsUsedInName uses deprecated methods
by moose-technology＠googlecode.com 03 Oct '12

03 Oct '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 835 by step...(a)stack.nl: MooseGroup symbolsUsedInName uses deprecated methods http://code.google.com/p/moose-technology/issues/detail?id=835 String withoutTrailingBlanks and withoutLeadingBlanks Fixed in Moose-MondrianPaintings-Stephan.Eggermont.170 in http://www.squeaksource.com/Moose Additional information: platform, context which may impact the problem Please fill in the labels with the following information: * Type-Defect * Component-Mondrian

1 1

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

← Newer
1
...
5
6
7
8
9
10
11
12
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2012