2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2015

moose-dev@list.inf.unibe.ch

32 participants
78 discussions

Start a nNew thread

[Glamour] default selection in ListPresentation

by Cyrille Delaunay

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

5 years, 2 months

3
4
0 / 0

[ann] gtspotter: a moldable interface for spotting objects

by Tudor Girba

Hi, Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit: GTSpotter, a novel interface for spotting objects. GTSpotter has two goals: - Provide a uniform yet moldable interface that can work on any object, and - Handle searching through arbitrary levels of object nesting. We think this will have a significant impact on the development workflow in Pharo. Here is a couple of screenshots: [image: Inline image 2] [image: Inline image 1] [image: Inline image 3] A trailer is available here: https://www.youtube.com/watch?v=PhSmjR3NOlU A detailed description is available here: http://www.humane-assessment.com/blog/introducing-gtspotter It works already in Pharo 3.0 and can be played with by following the instructions from: http://gt.moosetechnology.org Please let us know what you think. Enjoy, The Glamorous Team

5 years, 8 months

6
21
0 / 0

Issue 1103 in moose-technology: The list resulting of the Inspection of a MooseGroup should be in alphanumerical order

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1103 by v.blonde...(a)gmail.com: The list resulting of the Inspection of a MooseGroup should be in alphanumerical order https://code.google.com/p/moose-technology/issues/detail?id=1103 Describe the problem: what do you get? what do you expect? When you inspect with the moose panel (or an inspector) a model, the list of the group items are randomly sorted. I expect to have a alphanumerical sort on this list to quickly get an element of the list. How to reproduce the problem: step by step if necessary Do: LANPackageTestResource current model allClasses inspect. And go to the third tab (containing the list) Additional information: platform, context which may impact the problem Moose 5.0 Please fill in the labels with the following information: * Type-Enhancement * Component-GT -- 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

8 years, 2 months

1
2
0 / 0

Issue 1105 in moose-technology: Moose Importing Abstract Classes - Packages Reorganisation

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1105 by v.blonde...(a)gmail.com: Moose Importing Abstract Classes - Packages Reorganisation https://code.google.com/p/moose-technology/issues/detail?id=1105 The organisation of the Moose importers is a bit messy. The classe MooseAbstractImporter should be used by MooseImportingTask and be a subclass of MooseTask. MooseImportingTask is only used for smalltalk so it should be in Moose-SmalltalkImporter. And MooseOperator is not only for Smalltalk so it should be in the Moose-Core package. This following my mail from last year: http://www.iam.unibe.ch/pipermail/moose-dev/2014-April/019420.html and the discussion from 2011 from Usman and Stef: http://forum.world.st/Proposal-to-enhance-the-MooseTask-inheritance-and-M... Please fill in the labels with the following information: * Type-Engineering * Component-Moose -- 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

8 years, 2 months

1
2
0 / 0

Issue 896 in moose-technology: Roassal should offer a proper scrolling mechanism

by moose-technology＠googlecode.com

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

8 years, 3 months

3
12
0 / 0

Issue 956 in moose-technology: Problem of focus with GLM-Roassal

by moose-technology＠googlecode.com

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

8 years, 3 months

1
2
0 / 0

Issue 1004 in moose-technology: Roassal should offer circular treemaps

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal Milestone-5.0 New issue 1004 by tu...(a)tudorgirba.com: Roassal should offer circular treemaps http://code.google.com/p/moose-technology/issues/detail?id=1004 Rectangle treemaps are nice, but the still make it difficult to understand deep nesting. Circular treemaps do a better job there. It should not be hard to extend the TreeMapBuilder to support this. See here: http://lip.sourceforge.net/ctreemap.html -- 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

8 years, 3 months

1
6
0 / 0

Issue 915 in moose-technology: Roassal Mondrian - Circle with Text obscures text

by moose-technology＠googlecode.com

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

8 years, 3 months

1
3
0 / 0

PetitParser performance

by Usman Bhatti

Hi, Since the work on the integration of PPContext in PetitParser, there is significant performance degradation. I have already mentioned that on simple grammar the factor is about 2. But on complex grammar (for example, our proprietary parser for 4D language ), we have seen that degradation is goes well beyond this factor. So, for example, for 800K lines that we parse in under 10 minutes without PPContext work, with the latest version it goes beyond 2h. I have not been able to reproduce my case on simple grammars. May be we can have some benchmarks using open source parsers and large code bases (e.g. PP Java Parser on JHotDraw or ArgoUML). Currently, I circumvent this issue by using PP v1.51 but I can provide relevant feedback and run benches on any improvements. regards. Usman

8 years, 3 months

7
23
0 / 0

Roassal2: Heads/arrows on both ends of a line

by Jan Blizničenko

Hello We use Roassal 2 for visual side of a project we are working on - a diagram modelling tool (like enterprise architect) and we came to a specific need. There are notations like UML which need heads/arrows on both ends of a single line. As far as I understand the roassal code, line decorations are encoded to be at the "to" end and can't be on the other one. We would use help with this problem. Thanks Jan Blizničenko

8 years, 3 months

3
2
0 / 0

← Newer
1
2
3
4
5
6
7
8
Older →