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

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.

14 years, 3 months

Mondrian: MOEdge - draggable

by Veronica Isabel Uquillas Gomez

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

14 years, 3 months

Moose Chef

by Simon Denier

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

14 years, 3 months

Issue 522 in moose-technology: Add Enum and EnumValue to FAMIX

by moose-technology＠googlecode.com

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 }

14 years, 3 months

Re: Issue notifications in the mailing lists

by Alberto Bacchelli

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 >

14 years, 3 months

Issue notifications in the mailing lists

by Alberto Bacchelli

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

14 years, 3 months

Issue 519 in moose-technology: Add AnnotationTypeProperty and AnnotationInstanceProperty

by moose-technology＠googlecode.com

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 = "")

14 years, 3 months

Re: Issue 390 in moose-technology: MoqamBrowser does not need to put module marks in a dictionary

by moose-technology＠googlecode.com

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

14 years, 3 months

Issue 502 in moose-technology: Glamour rendering should offer closable tabs

by moose-technology＠googlecode.com

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.

14 years, 3 months

Re: Issue 345 in moose-technology: Close single tab / close all tab feature for Moose browser

by moose-technology＠googlecode.com

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

14 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev