Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Issue 523 in moose-technology: Selection actions should disable the shortcut when no selection exists
by moose-technology＠googlecode.com 08 Feb '11

08 Feb '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour New issue 523 by tudor.gi...(a)gmail.com: Selection actions should disable the shortcut when no selection exists http://code.google.com/p/moose-technology/issues/detail?id=523 The morphic renderer does not disable the shortcut for an action when no selection exists.

1 0

Mondrian: MOEdge - draggable
by Veronica Isabel Uquillas Gomez 08 Feb '11

08 Feb '11

Hi Alexandre, Some of my visualizations that are using #draggable are raising the error: MOEdge does not understand #translateBy:bounded: Did #draggable and #nodraggable change? Regards, Veronica

2 1

Moose Chef
by Simon Denier 07 Feb '11

07 Feb '11

Moose Chef is now part of Famix Core. A page describing the library and its usage is available at http://www.moosetechnology.org/docs/famix/MooseChef (basically the same stuff that was described in my mails a few days ago) -- Simon Denier

2 1

Issue 522 in moose-technology: Add Enum and EnumValue to FAMIX
by moose-technology＠googlecode.com 07 Feb '11

07 Feb '11

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Famix Milestone-4.3 New issue 522 by tudor.gi...(a)gmail.com: Add Enum and EnumValue to FAMIX http://code.google.com/p/moose-technology/issues/detail?id=522 The following Java snippet should be modeled with an Enum and 7 EnumValues. The Enum should be a type and the EnumValue should have a parentEnum pointing to the Enum. public enum Day { SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY }

1 1

Re: Issue notifications in the mailing lists
by Alberto Bacchelli 07 Feb '11

07 Feb '11

Alexandre and Doru, I see your point, and I see many other open source projects mixing issue notifications with the real development mails, thus corroborating it. However, I would say that the best setup would be using two different mailing lists, because many of the issue notifications are not informative at all (e.g., "Issue #x fixed.") and you get a wrong idea of how much "real" discussion is going on the list. Other projects, such as ArgoUML adopt the multi lists approach. For example Argo has these lists: org.tigris.argouml.announce org.tigris.argouml.commits org.tigris.argouml.dev org.tigris.argouml.issues org.tigris.argouml.modules-dev org.tigris.argouml.users I've seen development mailing lists without discussions but with 2000 emails per month generated only by the issue tracking system. If this will be the case with moose-dev, (and many of the emails are really generated by the issue tracker) I would try to consider something different from mailing lists to coordinate. In any case, this is my opinion, and it's up to you to decide. Of course, I can always filter emails out ;) Thanks for reading. Cheers, Alberto On 7 February 2011 14:20, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > I personally like the current setting. You can always filter out the mails you do not want to see > > Alexandre > > > > Le 7 févr. 2011 à 06:35, Alberto Bacchelli <alberto.bacchelli(a)usi.ch> a écrit : > >> Hi all, >> >> Why is the issue tracking system sending messages to this mailing list? >> >> Wouldn't it be better to have a second mailing list for issue notifications, >> so that moose-dev does not receive so many messages? >> >> We can always discuss here the issues that are worth-discussing, >> just by forwarding emails from the "issue notifications" mailing list to here. >> >> Just in my humble opinion. >> >> Alberto >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

2 1

Issue notifications in the mailing lists
by Alberto Bacchelli 07 Feb '11

07 Feb '11

Hi all, Why is the issue tracking system sending messages to this mailing list? Wouldn't it be better to have a second mailing list for issue notifications, so that moose-dev does not receive so many messages? We can always discuss here the issues that are worth-discussing, just by forwarding emails from the "issue notifications" mailing list to here. Just in my humble opinion. Alberto

3 2

Issue 519 in moose-technology: Add AnnotationTypeProperty and AnnotationInstanceProperty
by moose-technology＠googlecode.com 07 Feb '11

07 Feb '11

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Famix Milestone-4.3 New issue 519 by tudor.gi...(a)gmail.com: Add AnnotationTypeProperty and AnnotationInstanceProperty http://code.google.com/p/moose-technology/issues/detail?id=519 The AnnotationType should hold a collection of AnnotationTypeProperty. For example, below we would have 4 such properties attached to the MyAnno AnnotationType. public @interface MyAnno { int id(); String synopsis(); String engineer() default "[unassigned]"; String date() default "[unimplemented]"; } The AnnotationInstance should point to the AnnotationTypeProperty and hold a value. For example, below, the AnnotationInstance would have four AnnotationPropertyInstance, each pointing to the property type and having the value stored as string. @MyAnno(id = 0, synopsis = "")

1 1

Re: Issue 390 in moose-technology: MoqamBrowser does not need to put module marks in a dictionary
by moose-technology＠googlecode.com 07 Feb '11

07 Feb '11

Updates: Status: WontFix Comment #1 on issue 390 by simon.de...(a)gmail.com: MoqamBrowser does not need to put module marks in a dictionary http://code.google.com/p/moose-technology/issues/detail?id=390 Nobody working on Moqam for now

1 1

Issue 502 in moose-technology: Glamour rendering should offer closable tabs
by moose-technology＠googlecode.com 07 Feb '11

07 Feb '11

Status: Accepted Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.3 New issue 502 by tudor.gi...(a)gmail.com: Glamour rendering should offer closable tabs http://code.google.com/p/moose-technology/issues/detail?id=502 Currently, the rendering does not allow us to close tabs. This should be enabled for Accumulator.

3 6

Re: Issue 345 in moose-technology: Close single tab / close all tab feature for Moose browser
by moose-technology＠googlecode.com 07 Feb '11

07 Feb '11

Updates: Status: Duplicate Mergedinto: 502 Comment #2 on issue 345 by simon.de...(a)gmail.com: Close single tab / close all tab feature for Moose browser http://code.google.com/p/moose-technology/issues/detail?id=345 (No comment was entered for this change.)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev