Moose-dev August 2013

moose-dev@list.inf.unibe.ch

26 participants
167 discussions

[Glamour] default selection in ListPresentation
by Cyrille Delaunay 24 Mar '18

24 Mar '18

Hello, Is there a way to set a default selection to a list presentation? so that when I open the browser, the morphic list has already a value selected. I tried that: |tmpBrowser| tmpBrowser := GLMTabulator new. tmpBrowser row: #list. tmpBrowser transmit to: #list; andShow: [:a | a list display: [:input | input]; selection: #a; yourself ]. tmpBrowser openOn: #( b c d v a d f r). but the list still open with nothing selected

3 4

Issue 896 in moose-technology: Roassal should offer a proper scrolling mechanism
by moose-technology＠googlecode.com 04 Mar '15

04 Mar '15

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal New issue 896 by tu...(a)tudorgirba.com: Roassal should offer a proper scrolling mechanism http://code.google.com/p/moose-technology/issues/detail?id=896 For any visualisation that is larger than the screen, you immediately get lost in Roassal. Furthermore, the current dragging style does not scale for visualizations that are much larger on one dimension than the screen. We need a mechanism that helps us: - get an idea of where we are (and how much is left outside the current view) - have an easy way to actually scroll through a larger space

3 12

Issue 956 in moose-technology: Problem of focus with GLM-Roassal
by moose-technology＠googlecode.com 27 Feb '15

27 Feb '15

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Roassal New issue 956 by usman.bh...(a)gmail.com: Problem of focus with GLM-Roassal http://code.google.com/p/moose-technology/issues/detail?id=956 The focus is not correct in visualizations created with GLM-Roassal: The focus is centered on the lower right part of the diagram. So zooming-in hides the upper-left part of the diagram. To reproduce: Moose Finder -> a-Moose-Model -> all packages -> visualize -> Dependencies (cycles) -> zoom-in. -- 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

1 2

Issue 915 in moose-technology: Roassal Mondrian - Circle with Text obscures text
by moose-technology＠googlecode.com 27 Feb '15

27 Feb '15

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 915 by cunningh...(a)gmail.com: Roassal Mondrian - Circle with Text obscures text http://code.google.com/p/moose-technology/issues/detail?id=915 I want to draw a node in the diagram with a circle (actually, an ellipse) around it, which works. However, the circle obscures part of the text. If the text is multi-line, it obscures quite a bit, in fact. File in the attached extension to ROMondrianExmaple, then run: ROMondrianExample new labeledCircle You should see the issue. Latest Moose Suite 4.7, windows platform. Labels: Type-Enhancement Labels: Component-Roassal Attachments: LabeledCircle.1.cs 582 bytes -- 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

1 3

Re: Issue 890 in moose-technology: All meta-entities should have a class comment
by moose-technology＠googlecode.com 25 Nov '14

25 Nov '14

Updates: Summary: All meta-entities should have a class comment Comment #1 on issue 890 by tu...(a)tudorgirba.com: All meta-entities should have a class comment http://code.google.com/p/moose-technology/issues/detail?id=890 (No comment was entered for this change.)

1 4

Issue 816 in moose-technology: MooseMetaBrowser's Map re-display after selection of a node
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-MooseCore New issue 816 by anquetil...(a)gmail.com: MooseMetaBrowser's Map re-display after selection of a node http://code.google.com/p/moose-technology/issues/detail?id=816 In the Moose MetaBrowser, when selecting a node in the Map, this map is redisplayed at a new location which can even hide the selected node. How to reproduce the problem: - open MetaBrowser - the map (drawing) must be larger than the Map panel - scroll to the right of the map - select a node (at the right) - the map is redisplayed scrolled back to its initial position (full left) Same thing happens vertically (scroll down, select a node down, map is redisplayed from top)

1 10

Issue 514 in moose-technology: Introduce the PharoImageSourceAnchor
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-SmalltalkImporter Component-Famix New issue 514 by tudor.gi...(a)gmail.com: Introduce the PharoImageSourceAnchor http://code.google.com/p/moose-technology/issues/detail?id=514 Currently, FAMIXClass>>sourceText has a hack that checks for mooseModel isSmalltalk explicitly. We should introduce a PharoImageSourceAnchor that properly takes care of this.

1 1

Issue 973 in moose-technology: Roassal font organizer singleton inconsistencies
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 973 by benjamin...(a)gmail.com: Roassal font organizer singleton inconsistencies http://code.google.com/p/moose-technology/issues/detail?id=973 Following on from Issue 971, use of singletons related to the Roassal font organizer seems not used consistently. Using Finder, I've searched all 'Source' of Roassal packages, for the following both 'ROFontOrganizer' and 'fontOrganizerClass' and found... ----Part1-------------- ROAbstractLabel >> fontFor: anElement with: aCamera fo := ROPlatform current fontOrganizerClass. ROAbstractLabel >> offsetWhenDrawing ^ ROPlatform current fontOrganizerClass ROAbstractLabel >> widthOfLine: string withFont: aFont ^ ROFontOrganizer current widthOfString: string font: font. I propose the last is changed to... ROAbstractLabel >> widthOfLine: string withFont: aFont ^ ROPlatform current fontOrganizerClass widthOfString: string font: font. and also delete... ROFontOrganizer >> current ^ self subclasses first which seems plain wrong. ----Part2-------------- Also I'm a perplexed by the way both of these methods ROMorphicPlatform>>fontOrganizerClass ^ ROFontOrganizerMorphic ROPharoAthensPlatform>>fontOrganizerClass ^ ROFontOrganizerAthens override this one ROPlatform>>fontOrganizerClass ^ fontOrganizerClass such that the instance-variable 'fontOrganizerClass' is ignored, as well as the following seeming irrelevant... ROPlatform>>fontOrganizerClass: ^ fontOrganizerClass := aClass. Is ROPlatform ever instantiated, or abstract? A search for all references to 'ROPlatform' in the 'Source' of all Roassal finds... * ROPlatform current (x40) * ROPlatform platforms (x2) * ROPlatform removeNamed: (x1) * ROPlatform add: (x2) * ROPlatform setCurrent: (x1) * ROPlatform new (x1) The last is only in a test ROPlatformTest>>testAddingAPlatform. I propose to modify... ROPlatform>>fontOrganizerClass self subclassResponsibility delete.... fontOrganizerClass instance-variable delete... ROPlatform>>fontOrganizerClass: from... ROPlatformTest>>testAddingAPlatform remove line... platform fontOrganizerClass: ROFontOrganizer subclasses anyOne. hope this helps, cheers -ben -- 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

1 5

Issue 528 in moose-technology: Remove Category Importer
by moose-technology＠googlecode.com 12 Nov '14

12 Nov '14

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium Milestone-4.3 Component-Famix Component-SmalltalkImporter New issue 528 by jannik.l...(a)gmail.com: Remove Category Importer http://code.google.com/p/moose-technology/issues/detail?id=528 With RPackage, Category importer is useless, We should remove it. They are some referecnes in examples in DSM.

1 6

Re: Issue 228 in moose-technology: Nested browsers do not take "when", or "display" into account
by moose-technology＠googlecode.com 24 Jul '14

24 Jul '14

Updates: Labels: -Milestone-4.2 Comment #4 on issue 228 by tudor.gi...(a)gmail.com: Nested browsers do not take "when", or "display" into account http://code.google.com/p/moose-technology/issues/detail?id=228 (No comment was entered for this change.)

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev August 2013