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-VerveineJ
New issue 964 by anquetil...(a)gmail.com: <Initializer> methods created as
stub
http://code.google.com/p/moose-technology/issues/detail?id=964
When an attribute is initialized at declaration, the initialization code
goes in a <Initializer> method.
This one should not be a stub but it is
--
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
Hi Stef,
On Sun, Aug 11, 2013 at 3:19 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr
> wrote:
> ...
> To me I think that it would be good to have a Moosedev and a
> MooseDeployment part because we have many differnt frameworks in the system
>
This is certainly an important topic and it warrants its own discussion.
I think we should not distinguish between MooseDev and MooseDeployment :).
My vision goes like this:
- Moose is a platform that works for multiple technologies. Perhaps we can
distinguish between what makes sense for Java or for a language like C#,
but the differences would be small and would not warrant different
distributions.
- Moose is a platform for Pharo as well, although not many are seeing it
like that. This means that the tools we have with Moose should be used for
analyzing Pharo.
- We could distinguish between a Pharo only distribution and the
distribution for all other languages. Actually, this is what we have with
the GToolkit project: a Pharo specific toolset. However, we still want to
have the Pharo-specific tools inside a Java-specific distribution given
that we want people to develop their own tools fast. And to debug them. And
to inspect them. So we want all the Pharo specific tools in the large
distribution, too.
All in all, we now go towards:
- GToolkit for everyone that wants to develop in Pharo only.
- Moose for every other language (and it includes GToolkit).
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
ACD-Model
depends on MessageSendDebugAction
???
may be this one is the fix
package: 'ACD-Model' with: [spec requires: #('NewDebugger-Core' 'DebuggerActions)];
in AnnouncerCentricDebugger
To me I think that it would be good to have a Moosedev and a MooseDeployment part because we have many differnt frameworks in the system
Stef
Hi,
MooseImage is a new class that is meant to store meta-information about the
origin of the current image. Right now, this populated by the Jenkins build
job.
You can simply print the result of "MooseImage current" to find the
information
For example, you can get:
Moose
https://ci.inria.fr/moose/job/moose-latest-dev-4.8/855/
11 August 2013 3:23:43 pm
>From now on, we can identify our images better.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Maintainability
New issue 963 by tu...(a)tudorgirba.com: Jenkins should stamp a build number
in the Moose image
http://code.google.com/p/moose-technology/issues/detail?id=963
The best way to do this would be to extend the
MooseImageSetupCommandLineHandler to support a build number parameter.
--
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