Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Issue 1095 in moose-technology: PlayGround directory cache bug
by moose-technology＠googlecode.com 14 Nov '14

14 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-GlamorousToolkit New issue 1095 by anquetil...(a)gmail.com: PlayGround directory cache bug https://code.google.com/p/moose-technology/issues/detail?id=1095 opening on a computer an image coming from another computer When typing anything in the PlayGround, there is an exception (see attached). work areounf: go in System > Settings > GlamourousToolkit > LocalPlaygroundCacheDirectory and set it to a directory on local disk Attachments: Screenshot from 2014-11-03 16:41:02.png 141 KB -- 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

2 3

another GTPlayground problem
by Esteban Lorenzano 14 Nov '14

14 Nov '14

“tab” is broken :( Esteban

2 2

Fwd: Re: RTPNGExporter - review needed
by Nicolai Hess 14 Nov '14

14 Nov '14

Am 14.11.2014 00:57 schrieb "Chris Cunningham" <cunningham.cb(a)gmail.com>: > > Nah, morphic works. What you do is have it write to a canvas big enough to hold the drawing, then get the form under it, and then save that out. So, something like this in the morph: > > asForm > | canvas | > canvas := FormCanvas extent: self extent. > self drawOn: canvas. > ^canvas contentsOfArea: bounds > > and write it out with: > > PNGReadWriter putForm: morph asForm onFileNamed: 'someFileName.png' > > I've used this with rediculously large diagrams before. > > -chris Yes, pure morphic. But rendering the above Diagramm in a morphic window and with Athens (and therefore Cairo) only works, because it only renders the visible part. If you have a display with >32k width or hight, you would suffer from the same Problem.

3 2

latest GTPlayground ignoring DarkTheme colorisation
by Esteban Lorenzano 14 Nov '14

14 Nov '14

Hi, So… someone is hardcoding the shout theme… something in Rubric, perhaps? But well… playground became non-usable for me :( cheers, Esteban ps: the timestamp as title is also ugly. I propose to just remove that title. Is useless anyway (toolbar icons can be replaced by a menu/toolbar for window, no need of a pane with an unique tab there). pps: the menu options are arbitrary in his relevancy and I still miss some of the options (already reported) ppps: lots of uncategorised methods in GLMMorphicPharoPlaygroundRenderer and around pppps: got it, RubSHTextStylerST80 does not respect style, and uses always default style (that’s obviously not cool :p).

3 2

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 1003 in moose-technology: The treemap builder should offer a default weight of 1
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Roassal Milestone-5.0 New issue 1003 by tu...(a)tudorgirba.com: The treemap builder should offer a default weight of 1 http://code.google.com/p/moose-technology/issues/detail?id=1003 Right now, the weight block has to be specified. Instead, we should have a default weight of 1. Furthermore, right now, if the weight returns 0 (like above), we get a ZeroDivide. Zero should be handled without an error. -- 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

Re: Issue 674 in moose-technology: Bullet graphs in Graph-ET
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Updates: Summary: Bullet graphs in Graph-ET Labels: -Component-EyeSee Comment #2 on issue 674 by tu...(a)tudorgirba.com: Bullet graphs in Graph-ET http://code.google.com/p/moose-technology/issues/detail?id=674 I changed the topic to be related to Graph-ET :) -- 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 1

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

Re: Issue 393 in moose-technology: Interactive sort of table widget by columns
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Updates: Cc: simon.de...(a)gmail.com tudor.gi...(a)gmail.com Comment #1 on issue 393 by tu...(a)tudorgirba.com: Interactive sort of table widget by columns http://code.google.com/p/moose-technology/issues/detail?id=393 Issue 156 has been merged into this issue. -- 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 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev