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.
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.'
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.
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
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 ].
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
Status: New
Owner: ----
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.7
New issue 798 by tudor.gi...(a)gmail.com: Mondrian should store edges in the
most specific parent of the from/to nodes
http://code.google.com/p/moose-technology/issues/detail?id=798
The edges should be stored in the most specific parent of the from and to
nodes, and not in the parent of the node in which they are defined.
This is because the layout takes this information into account. For
example, the below layout does not show a tree inside node 1.
view := MOViewRenderer new.
view node: 1 forIt: [
view shape label.
view nodes: (10 to: 11).
view treeLayout.
].
view edgesFromAssociations: {10 -> 11}.
view open.
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.