Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Re: Issue 155 in moose-technology: Port EyeSee to Pharo

by moose-technology＠googlecode.com

Updates: Status: Fixed Labels: Milestone-4.4 Component-EyeSee Comment #5 on issue 155 by tudor.gi...(a)gmail.com: Port EyeSee to Pharo http://code.google.com/p/moose-technology/issues/detail?id=155 It is working quite well now. We can close this issue and open more specific ones if needed.

14 years, 1 month

Issue 540 in moose-technology: Glamour: removing dependency in configuration - core group

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 540 by vuqui...(a)vub.ac.be: Glamour: removing dependency in configuration - core group http://code.google.com/p/moose-technology/issues/detail?id=540 In the configuration of Glamour, the core group was loading only Glamour packages, and the extras group: mondrian and magritte presentations. This allowed to load those presentations if needed. Currently, the core group is also depending on Mondrian. The method MOViewRenderer>>openWithStatusbar is causing this dependency in the package Glamour-Scripting. Can this dependency be removed from the group core? * Type-Enhancement * Component-Glamour

14 years, 1 month

glamorous theme changes

by Tudor Girba

Hi, The GLMUITheme changed: - no more color fading, except for selected buttons and tabs - more contrast between grays - fixed the issue with lighter background color for inactive windows This resulted in a simpler and slightly faster look. Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice."

14 years, 1 month

Re: Issue 448 in moose-technology: MOEaselTextEditor contains many methods that are never called

by moose-technology＠googlecode.com

Comment #1 on issue 448 by tudor.gi...(a)gmail.com: MOEaselTextEditor contains many methods that are never called http://code.google.com/p/moose-technology/issues/detail?id=448 Is this still a problem? And what is /branches/?

14 years, 1 month

Re: Issue 460 in moose-technology: scaleBy: should be in shapes, and not in MONode

by moose-technology＠googlecode.com

Updates: Labels: Component-Mondrian Comment #1 on issue 460 by jannik.l...(a)gmail.com: scaleBy: should be in shapes, and not in MONode http://code.google.com/p/moose-technology/issues/detail?id=460 (No comment was entered for this change.)

14 years, 1 month

Re: Issue 266 in moose-technology: UMLClassDiagram

by moose-technology＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 266 by alexandr...(a)gmail.com: UMLClassDiagram http://code.google.com/p/moose-technology/issues/detail?id=266 I fixed this a couple of days ago. About the white space below the text I open a new issue

14 years, 1 month

Re: Issue 446 in moose-technology: uml class shape aligned the rectangles

by moose-technology＠googlecode.com

Updates: Status: Accepted Labels: -Priority-Medium Priority-High Comment #4 on issue 446 by tudor.gi...(a)gmail.com: uml class shape aligned the rectangles http://code.google.com/p/moose-technology/issues/detail?id=446 A form of the problem is still around. This is an important issue that prevents us from actually using the FormsBuilder. Here is an example with a ChildrenShape inside. The green shape on top should have a constant minimum size. Instead its height increases together with the height of the children shape below: | builder | builder := MOFormsBuilder new. builder column; fill. builder row; fill; row; fill. builder x: 1 y: 1 add: (MORectangleShape new width: 30; fillColor: Color green). builder x: 1 y: 2 add: (MORectangleShape new). builder x: 1 y: 2 add: (MOChildrenShape new). view shape: builder shape. view nodes: (1 to: 5) forEach: [:each | view nodes: (1 to: each). view verticalLineLayout ]

14 years, 1 month

Issue 578 in moose-technology: Add Kumpel to ConfigurationOfMoose

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Kumpel Component-MooseCore Milestone-4.4 New issue 578 by tudor.gi...(a)gmail.com: Add Kumpel to ConfigurationOfMoose http://code.google.com/p/moose-technology/issues/detail?id=578 Just that.

14 years, 1 month

Problem worth working on

by Alexandre Bergel

Hi! Since some of you are working on remodularizing code, maybe the following may inspire you. In Mondrian, the tests are badly structured. I actually wrote a large part of them as a way for me to understand the initial version of Mondrian, back in 2007-2008. Most of the tests are contained in the class MOViewRendererTest. They actually contain a lot of duplicated scenario (not really code): I open a canvas, put some nodes and edges, run the layout... I would like to cut this class into smaller unit tests. Fixture will have to be found for each new unit tests. How to structure them? Along the class hierarchy? Along the features of Mondrian? Along the features commonly used in Mondrian scripts (which is how they are roughly structured)? I can remodularize my tests and come up with a satisfactory design in a couple of hours. But maybe someone worked on a tool that would help me on this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 1 month

A window to see all the time the code

by Stéphane Ducasse

Hi guys now that we have announcements it should be easy to have a code spy: a window that when I browse any things in moose (being it a mondrian node, or a whatever stuff announcement event) I could see in the spy window the code of the entity. This way I could move hyperfast my mouse on a nice mondrian view and get immediately fats code overview wihtout having to click, spawn or wahtever action. Do you like the idea? Because I always got frustrtaed with visualaition because I could not get that behavior in addition to the visualization. Stef

14 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev