Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Roassal
New issue 938 by tu...(a)tudorgirba.com: RadialTreeLayout should translate
the graph
http://code.google.com/p/moose-technology/issues/detail?id=938
Try this:
view nodes: (Collection withAllSubclasses).
view edgesFrom: #superclass.
view radialTreeLayout.
The center of the graph is placed at 0@0, and this is annoying because you
do not see half of the graph. The layout should translate the graph to make
it start at 0@0
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: tu...(a)tudorgirba.com
CC: chisvasi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Glamour
New issue 884 by tu...(a)tudorgirba.com: The Roassal presentation should
react to custom ports
http://code.google.com/p/moose-technology/issues/detail?id=884
The current implementation of the Roassal presentation relies only on the
original entity. However, given that Roassal can handle various animations,
we would benefit from an extra ability of the presentation to react to
other ports.
For example, the list presentation reacts to #selection. Similarly, Roassal
should be able to react to it or others as well. Only, given that Roassal
is generic, the reaction should be customisable, too.
Perhaps something like this:
a roassal
painting: [:view :entity | ... ]
on: #customPort do: [ :view :customValue | ... ]
Hi guys,
For those working in information retrieval, for example for doing td-idf
ranking, you can find adapted packages: "Hapax" and "CodeFu" in the
BioSmalltalk repository http://ss3.gemstone.com/ss/BioSmalltalk.html . I
have translated some VW specific code to Pharo 1.4 (under Windows
requires the ProcessWrapper package) and adapted some Hapax methods to
work with corpus in different languages.
This is an example script for a corpus in Spanish:
| corpus tdm documents |
corpus := HXSpanishCorpus new.
documents := 'el río Danubio pasa por Viena, su color es azul
el caudal de un río asciende en Invierno
el río Rhin y el río Danubio tienen mucho caudal
si un río es navegable, es porque tiene mucho caudal'.
documents lines doWithIndex: [: doc : index |
corpus
addDocument: index asString
with: (Terms new
addString: doc
using: CamelcaseScanner;
yourself)].
corpus removeStopwords.
corpus stemAll.
tdm := TermDocumentMatrix on: corpus.
Feel free to integrate to any repository. If you want to add a language
just see methods with selectors including "spanish".
Cheers,
Hernán
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-High Component-VerveineJ
New issue 714 by tudor.gi...(a)gmail.com: VerveineJ does not produce correct
values for classes in annotation instances
http://code.google.com/p/moose-technology/issues/detail?id=714
Take a look at the example below:
@XmlElement(name = "Time", required = true, type = String.class)
protected Date time;
The value of the third attribute of the annotation instance is the actual
source code of the String class. Instead, it should be just the
string 'String.class'.
Ideally, we would get an actual reference, but the string would do for now.
Status: New
Owner: ----
CC: alexandr...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Component-Roassal
New issue 888 by tu...(a)tudorgirba.com: MondrianViewBuilder should support a
better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888
Here is a little example:
view shape label text: #yourself.
view nodes: (1 to: 20).
view edges: (1 to: 20) from: [:x | x // 2] to: 1.
view edges: (1 to: 20) from: [:x | x // 3] to: 2.
view edges: (1 to: 20) from: [:x | x // 5] to: #yourself.
view edges: (1 to: 20) from: [:x | x // 7] to: #yourself.
view dominanceTreeLayout
Open this one is Mondrian and then in the Roassal Easel.
Then, try to select 1.
In Roassal, you cannot select 1 because of the edges that go on top of it.
What is more, you also can barely see it. This situation will always appear
in graphs with edges that cross the nodes.
Given that at least the MondrianViewBuilder should be about mapping domain
models onto graphs, having a sensible zOrder, at least in the
MondrianViewBuilder is important.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Glamour
New issue 801 by tudor.gi...(a)gmail.com: MorphTreeMorph does not properly
support custom selection on Windows
http://code.google.com/p/moose-technology/issues/detail?id=801
Open a MorphTreeMorph and then try to press Alt+Click to select multiple
elements. This does not work on Windows (but it works on Mac using Command).
However, selecting a range using Shift+Click works just fine.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 857 by benjamin...(a)gmail.com: ROCircle strange MNU #extent:
http://code.google.com/p/moose-technology/issues/detail?id=857
With ConfigurationOfRoassal.667 just loaded, my project application popped
up a 'MNU: receiver of "extent:" is nil, but as you can see in the attached
screen snapshot, which has the default debugger highlighting showing the
current executiong, the receiver is the ivar 'next' which is actually _not_
nil, but an instance of RONullShape. Strange...
As a test case, executing the following in Rossal Easel caused the same MNU.
=========
rawView add: (ROElement on: 1) + ROCircle.
=========
Fixed it with: Compiler recompileAll. This actually has happened to me a
few times in past couple of weeks.
(Note actually the example code gives a really tiny circle and #spriteOn:
would have been better than #on:)
Attachments:
ROCircle-MNU-extent.png 34.6 KB
Hi
I'm working on Radial tree to make ti take node size into
account.
I've tried some few things about mixing layout, and it seems
to work. (I'll commit it in the week, and send you a mail then)
Then I
have some questions :
If the layout can't change node size, then what
can do it ? Is it the aim of Normalizers ?