Moose-dev

moose-dev@list.inf.unibe.ch

6630 discussions

Re: Issue 1124 in moose-technology: Glamour: Render Morphs in Scroll Panes

by moose-technology＠googlecode.com

Updates: Summary: Glamour: Render Morphs in Scroll Panes Labels: -Type-Defect -Component-GlamorousToolkit Type-Enhancement Component-Glamour Comment #3 on issue 1124 by sean.p.d...(a)gmail.com: Glamour: Render Morphs in Scroll Panes https://code.google.com/p/moose-technology/issues/detail?id=1124 It seemed like the most logical place to patch was in the Glamour renderer. Is that okay for everyone? N.B. Issue title changed from "... GT..." -> "... Glamour..." -- 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

9 years, 5 months

Change in class blueprint

by Alexandre Bergel

Hi! I am updating some code found in class blueprint. I have migrated the method: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= createEdgesFor: aClass andLayers: layers on: view (RTEdge buildEdgesFromObjects: aClass incomingAccesses from: #from to: #to using: (RTLine new color: Color lightBlue; attachPoint: RTHorizontalAttachPoint instance) inView: view) do: [ :each | each moveBehind: (layers flatCollect: #value) ]. (RTEdge buildEdgesFromObjects: aClass outgoingInvocations from: #from to: [ :each | each candidates detect: [ :c | c typeScope = aClass ] ifNone: [ nil ] ] using: (RTLine new attachPoint: RTHorizontalAttachPoint instance) inView: view) do: [ :each | each moveBehind: (layers flatCollect: #value) ] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= to: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= createEdgesFor: aClass andLayers: layers on: view | eb edges to | eb := RTEdgeBuilder new. eb view: view. eb shape line; color: Color lightBlue; horizontalAttachPoint. edges := aClass incomingAccesses flatCollect: [ :acc | eb connectFrom: acc from to: acc to ]. edges do: [ :each | each moveBehind: (layers flatCollect: #value) ]. eb := RTEdgeBuilder new. eb view: view. eb shape line; horizontalAttachPoint. to := [ :each | each candidates detect: [ :c | c typeScope = aClass ] ifNone: [ nil ] ]. edges := aClass outgoingInvocations flatCollect: [ :acc | eb connectFrom: acc from to: (to value: acc) ]. edges do: [ :each | each moveBehind: (layers flatCollect: #value) ] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I thought about a #source: on the EdgeBuilder, but I am not sure this will be really useful... I think this does not change the behavior… but we never know. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 5 months

Roassal RTAttachPoint inverted

by Peter Uhnák

Hi Alex, I've noticed that with addition of DoubleArrowedLine you've also added concept of "inverted" to attach points. This seems really strange from the perspective that all methods startingPointOf: and endingPointOf: are identical only with swapped ifTrue:/ifFalse: for example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ startingPointOf: anEdge ^ (inverted ifTrue:[anEdge to] ifFalse:[anEdge from]) position endingPointOf: anEdge ^ (inverted ifTrue: [anEdge from] ifFalse: [anEdge to]) position ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ this is harder to read and more error-prone than ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ startingPointOf: anEdge ^ anEdge from position endingPointOf: anEdge ^ anEdge to position ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ plus there is code duplication. And this is just the simplest attach point. Since I should also add "inverted" to my attach points that are in Roassal (RTRectangleAttachPoint, ...) maybe the actual computation should be delegated? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RTAttachPoint>>startingPointOf: anEdge ^ inverted ifTrue: [ self basicEndingPointOf: anEdge ] ifFalse: [ self basicStartingPointOf: anEdge ] RTAttachPoint>>endingPointOf: anEdge ^ inverted ifTrue: [ self basicStartingPointOf: anEdge ] ifFalse: [ self basicEndingPointOf: anEdge ] RTAttachPoint>>basicStartingPointOf: anEdge ^ self subclassResponsibility RTAttachPoint>>basicEndingPointOf: anEdge ^ self subclassResponsibility ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This also will not break current implementation but it will give opportunity to improve them. And if there was a situation where the implementation would be actually different for inverted (and not just swapped values), than you could still just implement startingPointOf:/endingPointOf: Thanks, Peter

9 years, 5 months

Issue 1124 in moose-technology: GT: Render Morphs in Scroll Panes

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-GlamorousToolkit New issue 1124 by sean.p.d...(a)gmail.com: GT: Render Morphs in Scroll Panes https://code.google.com/p/moose-technology/issues/detail?id=1124 Right now, large Morphs are hard to deal with in GT. You only see the tiny fraction that fits in the pane. InspectIt: Morph new extent: (1000@1000); yourself Fix incoming... -- 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

9 years, 5 months

[ENH]: Issue 1124: GT: Render Morphs in Scroll Panes

by Sean P. DeNigris

Issue 1124: GT: Render Morphs in Scroll Panes https://code.google.com/p/moose-technology/issues/detail?id=1124 Right now, large Morphs are hard to deal with in GT. You only see the tiny fraction that fits in the pane. InspectIt: Morph new extent: (1000@1000); yourself. Fix attached to Google issue. <http://forum.world.st/file/n4840678/Screenshot_2015-08-01_19.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/ENH-Issue-1124-GT-Render-Morphs-in-Scroll-Panes-tp484… Sent from the Moose mailing list archive at Nabble.com.

9 years, 5 months

Roassal on Bloc on not Pharo

by Peter Uhnák

Hi, I am wondering... how will moving Roassal to Bloc affect other platforms such as VisualWorks? Because it seems it would be unportable with Bloc, no? Peter

9 years, 5 months

TRCanvas inspector

by Peter Uhnák

Why is TRCanvas rendered in inspector using RTView? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TRCanvas>>gtInspectorViewIn: composite <gtInspectorPresentationOrder: -10> composite roassal2 title: 'Canvas'; initializeView: [ RTView new setCanvas: self ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ shouldn't this be isolated from Roassal layer? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TRCanvas>>gtInspectorCanvasIn: composite <gtInspectorPresentationOrder: -20> composite morph title: 'Canvas'; morph: [ self buildMorph. self morph ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter

9 years, 5 months

Refactoring GT Presentations

by Sean P. DeNigris

It would be nice if the implementations were a bit more standard. I was trying to extract "render in scroll pane" from the Magritte presentation, but each presentation has a slightly different message to create the morph e.g. #magritteMorphFor:, #morph, and #morphFor:, so I had to do something uglier than I wanted. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Refactoring-GT-Presentations-tp4840672.html Sent from the Moose mailing list archive at Nabble.com.

9 years, 5 months

Large API vs Builder like API

by Alexandre Bergel

Hi! It would be great to get feedback from you guys. We have the class TRConstraint that allows for roassal elements to be aligned (cf Section 10 in https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010…>). Currently, you can write: TRConstraint use: centralDot alignFromTop: negativeElements Which align all the elements contained in the collection negativeElements against a fix point, centralDot. It looks pretty easy to read. However, the class TRConstraint has many methods (alignFromBottom:, alignFromLeft:, use: aShape alignFromBottom: shapes, …) which are essentially all duplicated code. So, I though about creating a compact class, called RTAlignment. You can now write: RTAlignment new elements: negativeElements; fixedElement: centralDot; top But, I find that less nice to read. Any opinion? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 5 months

News about the new version of MooseChef and questions

by Anne Etien

Hi, We have improved MooseChef with a generic version MooseQuery. In the following when we talk about MooseChef, it means the current version available by default in Moose. When we talk about MooseQuery, it means the generic improved version, available on Anne’s smalltalkHub repository. All the tests of MooseChef except 4 are passing when using our new MooseQuery API. These four tests concern the same point package scope for extension method. Considering classA having a method methodA1 calling a method methodBExt1 that extends classB. classB is defined in pckgB and its extension method by pckgC. Considering the two following requests: 1. classA queryOutgoingInvocation atClassScope atPackageScope 2. classA queryOutgoingInvocation atPackageScope To the first query, MooseChef and MooseQuery answer the same: pckgB To the second query, MooseChef answers pckgC and MooseQuery answers pckgB and pckgC. So first question: What is the expected behavior? What do we want? According to us, MooseQuery behavior is more consistent. *************** Considering now Java code. class1 contains a method method1 which in its turn contains an inner class innerClass2. innerClass2 contains 2 methods method21 and method22. the following query: innerClass2 methodScope In MooseChef this query has for result method21 and method22. The following query: innerClass2 atScope: FAMIXMethod In MooseQuery this query has for result method1. Indeed, the atScope: method look for the container (also called parent). So the second question: what is the expected behavior? Do we want like in MooseQuery that atScope: by default always goes up in the containment tree since it is a generic version of atTypeScope, atPackageScope... and do we want another method to goes down in the containment tree? In MooseChef, methodScope, always goes down to look for the contained methods. typeScope always goes up except for ScopingEntities. These methods have been implemented for each type of entities. It is what we want to avoid with MooseQuery. ****************** It is clear that Synectique will soon migrate to this new version and that our project of SQL analysis will also use it. Please don’t hesitate to use it. MCHttpRepository location: 'http://smalltalkhub.com/mc/AnneEtien/MooseQueryDraft/main' user: '' password: ‘' We will do as soon as possible a small doc to explain the usage. Thank you in advance for your answer to our questions. Jean-Christophe and Anne

9 years, 5 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