- Moose-dev - INF Mailman

by Alexandre Bergel

Hi! I am experiencing a weird behavior when rotating text: an extra space seems to have been inserted. For example the screenshot shows ‘J anu ary’. Anyone has seen this before? Any idea how to fix it? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 11 months

2
2
0 0

Roassal TRConstraint deprecation

by Peter Uhnák

Hi Alex, you've marked TRConstraint as obsolete, however not all behavior has been yet implemented in new RTConstraint. Namely methods from "public - resizing", "public - camera", and "public - aligning". Secondly I am not sure about the name of RTConstraint class>>child:parent: (Tudor also didn't like the name when he saw it. :)) I don't think the naming fits well into Roassal... maybe RTConstraint class>>on:backElement: ? Thanks, Peter

9 years, 11 months

2
3
0 0

RTEdgeBuilder very strange behavior

by Peter Uhnák

Hi Alex, I've encountered a very strange behavior and I cannot tell what is going on. This is old RTEdge build* ~~~~~~~~~~~~~~~~~~~~~ | v es | v := RTView new. es := RTBox elementsOn: (1 to: 10). v addAll: es. es @ RTDraggable. RTEdge buildEdgesFromObjects: (1 to: 10) from: #yourself toAll: [:value | (Array with: value -1 with: value + 1 with: value + 2) ] inView: v. RTForceBasedLayout on: es. v addAnimation: (RTSpringLayoutStepping new view: v). v @ RTDraggableView. ^ v ~~~~~~~~~~~~~~~~~~~~~~~~ the layouting is almost instant, however if I use RTEdgeBuilder suddenly it is very slow ~~~~~~~~~~~~~~~~~~~~~~~~ | v es | v := RTView new. es := RTBox elementsOn: (1 to: 10). v addAll: es. es @ RTDraggable. RTEdgeBuilder new view: v; elements: es; connectToAll: [:value | (Array with: value -1 with: value + 1 with: value + 2) ]. RTForceBasedLayout on: es. v addAnimation: (RTSpringLayoutStepping new view: v). v @ RTDraggableView. ^ v ~~~~~~~~~~~~~~~~~~~~~~~~~~ the view still has the same number of elements and edges and the output looks identical, but with EdgeBuilder is it very slow. Profiler is showing me that with EdgeBuilder it spends a lot of time in attach points and with moving edges, which is strange. In either case it has no right to be so slow with 10 elements and 26 edges... Can you reproduce this behavior? Thanks, Peter

9 years, 11 months

2
1
0 0

Glamour Magritte Example Broken

by Gareth Cox

Hi all I've just tried to use GLMAnnouncingCollection and found something odd. When you use it and its passed into a block (such as TableColumn computation:) it passes in the whole collection, not each item. Change the collection to OrderedCollection and it works as expected (except you lose the behaviour of GLMAnnouncingCollection). So, to find out how this is used I go to the examples provided, specifically "Magritte presentation". This has the following comment: "self new magritte openOn: GLMMagrittePersonExample sampleData" "GLMMagrittePersonExample sampleReset" "note, sampleData is aGLMAnnouncingCollection" This does not work as expected (or indeed how it used to). I've looked at this before and done work with Magritte using this example with Diego Lont and Stephan Eggermont. Its definitely become broken since the last time I looked at it. Can we confirm? Thanks -- Gareth Cox IT Manager/Developer Inspired Org (PTY) Ltd email: gareth(a)inspired.org <mailto:gareth@inspired.org>

9 years, 11 months

1
0
0 0

Re: [Pharo-dev] GanttChartMorph openOn: aCollectionOfActivities ?

by Alexandre Bergel

Hi Hannes! Here is a first shoot paired-programmed with Juraj using Roassal: -=-=-=-=-=-=-=-=-=-=-=-= b := RTTimeLine new. b addEntry: (RTTimeLineEntry new identifier: #WP1; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #WP2; start: 5; end: 8). b addEntry: (RTTimeLineEntry new identifier: #WP3; start: 7; end: 10). b axisX numberOfLabels: 5. b -=-=-=-=-=-=-=-=-=-=-=-= Here some slightly more elaborated example: -=-=-=-=-=-=-=-=-=-=-=-= “One color per entry" | b d | b := RTTimeLine new. b addEntry: (RTTimeLineEntry new identifier: #c1; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c1; start: 6; end: 8). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 8; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c3; start: 0; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c4; start: 5; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c5; start: 5; end: 8). d := RTVerticalTickLineDecorator new. d shape line color: Color white. b addDecorator: d. b axisX numberOfLabels: 5; labelRotation: -45; labelConversion: [ :v | Date year: 2015 day: v ]. b shape color: (RTMultiLinearColorForIdentity new objects: b entries). b -=-=-=-=-=-=-=-=-=-=-=-= One color per timeline -=-=-=-=-=-=-=-=-=-=-=-= | b | b := RTTimeLine new. b addEntry: (RTTimeLineEntry new identifier: #c1; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c1; start: 6; end: 8). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 8; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c3; start: 0; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c4; start: 5; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c5; start: 5; end: 8). d := RTVerticalTickLineDecorator new. d shape line color: Color white. b addDecorator: d. b axisX numberOfLabels: 5; labelRotation: -45; labelConversion: [ :v | Date year: 2015 day: v ]. b shape color: (RTMultiLinearColorForIdentity new command: #identifier; objects: #(c1 c2 c3 c4 c5)). b -=-=-=-=-=-=-=-=-=-=-=-= Age of some classes: -=-=-=-=-=-=-=-=-=-=-=-= | b | b := RTTimeLine new. b extent: 500 @ 500. ((RTShape withAllSubclasses sortedAs: #ageInDaysRounded) select: #hasMethods) do: [ :cls | e := RTTimeLineEntry new. e identifier: cls. e start: cls computeYoungestMethod ageInDays. e end: cls computeOldestMethod ageInDays. b addEntry: e ]. b -=-=-=-=-=-=-=-=-=-=-=-= All these examples are in the Roassal time line example menu. This is still an early version. Let us know how it goes! https://www.facebook.com/ObjectProfile/posts/840542572699008 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 7, 2015, at 4:25 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > Hello > > Has somebody done a GANTT chart? > > GanttChartMorph openOn: aCollectionOfActivities > > ? > > Activities have > - id > - description > - start date > - end date > ? > > Regards > > Hannes >

9 years, 11 months

2
17
0 0

Contribution Process

by Sean P. DeNigris

What is the process? Is it written anywhere? Wherever commits go, will you please add me? In the mean time, I attached the fix for 1124 to the Google issue ----- Cheers, Sean -- View this message in context: http://forum.world.st/Contribution-Process-tp4840680.html Sent from the Moose mailing list archive at Nabble.com.

9 years, 11 months

3
6
0 0

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, 11 months

1
0
0 0

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, 11 months

1
0
0 0

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, 11 months

2
1
0 0

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, 11 months

1
2
0 0

[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, 11 months

1
0
0 0

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, 11 months

6
9
0 0

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, 11 months

3
4
0 0

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, 11 months

1
0
0 0

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, 11 months

3
2
0 0

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, 11 months

4
11
0 0

Distribution/Color Map of file size

by Brice GOVIN

Hi, yesterday I heard someone from my team talking about a tool for visualizing quickly file size in your system. I was wondering if there is anything done with Roassal for that? I looked at the current version of Roassal in Moose 6.0 but I didnt find anything. If there is one could someone help me otherwise should it not be nice to have some? Thanks for your answer. Regards, -------------- Brice Govin PhD student in RMoD research team at INRIA Lille Software Engineer at THALES AIR SYSTEMS Rungis ENSTA-Bretagne ENSI2014 64 chemin des boeufs 91220 PALAISEAU

9 years, 11 months

3
4
0 0

ForceLayout is slow for too many elements.

by Demian Schkolnik

Hi all! I want to make a visualization of a graph (nodes and edges), but applying ForceLayout to it takes forever, because the graph has too many elements. if I apply TreeLayout, for example, the view renders almost instantly. Is there some other Layout, similar to ForceLayout, but faster, for so many elements? Thanks!

9 years, 11 months

4
9
0 0

[Roassal] Where is RTData?

by roberto.minelli＠usi.ch

Hi, Few days ago I built a view using the class RTData. With the last version of Roassal.. puff... disappeared… I read the discussion 'New RTData class in Roassal’ and it looks is the one to use. Am I right? Cheers, R

9 years, 11 months

2
3
0 0

FAMIXPetitSQLIslandTests class

by Fabrizio Perin

Hello, I was checking on FAMIXSQL and there is this test class that fails becuase it depends on the PetitSQLIslandParser package. I think this class is not belong here. Can we move it into a PetitSQLIslandParser package? Thanks and cheers, Fabrizio

9 years, 11 months

2
5
0 0

Conditional layout

by Alexandre Bergel

Dear all, I have created a class RTConditionalLayout and it is into the Layout Builder. Consider the following example: -=-=-=-=-=-=-=-=-= v := RTView new. es := (RTEllipse new size: 30; color: [ :value | value odd ifTrue: [ Color red ] ifFalse: [ Color blue ] ]) elementsOn: (1 to: 4). v addAll: es. l := RTConditionalLayout new condition: [ :element | element model odd ]; thenLayout: RTVerticalLineLayout new; elseLayout: RTHorizontalLineLayout new. l on: es. v -=-=-=-=-=-=-=-=-= The idea is to have a layout that segregate some elements that match a particular condition. This is supported in the Layout builder, which allows one to do (using RTMondrian in that case): -=-=-=-=-=-=-=-=-= b := RTMondrian new. b shape rectangle fillColor: Color white; borderColor: Color lightGray; withTextAbove: #name. b nodes: Collection withAllSubclasses forEach: [ :cls | b nodes: cls methods. b edges connectToAll: #dependentMethods. b layout ifElement: #isConnected then: RTTreeLayout new; else: RTGridLayout new. ]. b edges connectFrom: #superclass. b layout tree. b -=-=-=-=-=-=-=-=-= The issue here is that I have introduced a mechanism to do ‘if’ statements. I am not sure this is the best things… Comments are welcome :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 11 months

2
2
0 0

Rewrite of RTEdgeBuilder

by Alexandre Bergel

Dear All, RTEdgeBuilder has been completely rewritten. You can now specific objects and elements from where edges begins and edges. The API is about 70% the same I believe. Migration of your code should be fairly easy. Else, ask for help. In any case, the old builder is named: RTEdgeBuilderDeprecated Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 11 months

2
2
0 0

Glamour Tabs not updated when update is called

by Gareth Cox

Hi All Not sure if this is a bug, but here goes. Looking through the Glamour examples in Pharo4 I come across the Updateable Browser example. This example has a line that, when the collection is greater than 1, shows a list tab, the title of which is List, col size printString. This indeed comes up and shows: 'List: 2' but if you continue to add, it doesn't change. The text will change but not the title. I came across this when I couldn't get my browser to add tabs, even though entity gets updated. Example from Glamour below. | browser collection| collection := GLMAnnouncingCollection new. collection add: 1. browser := GLMTabulator new. browser column: #preview. browser act: [:b | b entity add: (b entity size + 1). b update ] icon: GLMUIThemeExtraIcons glamorousAdd entitled: 'Add an item in the collection'. browser act: [:b | b entity removeLast. b update ] icon: GLMUIThemeExtraIcons glamorousRemove entitled: 'Remove last item from the collection'. browser updateOn: GLMItemAdded from: #yourself; updateOn: GLMItemRemoved from: #yourself. browser transmit to: #preview; andShow: [ :a | a list title: [:col | 'List: ', col size printString ]; *"This isn't updating"* when: [:col | col size > 1 ]. a text title: 'Text'; format: [:col | 'Current collection: ', col printString, '. Add more items to show the list'] ]. browser openOn: collection KR -- Gareth Cox IT Manager/Developer Inspired Org (PTY) Ltd email: gareth(a)inspired.org <mailto:gareth@inspired.org>

9 years, 11 months

2
1
0 0

Snippets

by Peter Uhnák

Hi, are snippets (presented at ESUG) available anywhere? Peter

9 years, 11 months

2
1
0 0

Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

by Peter Uhnák

Hi Alex, I think that TRDrag* events should require that you are over the dragged element with your mouse, because now the behavior is that if the mouse gets outside the element, drag events are still being fired. But maybe I should fix this on my side. To better illustrate my point look at this https://www.youtube.com/watch?v=4rHdiwGdr4s When the mouse is completely out of the element the resizing is still occurring (because the drag event is still being applied), and then compare it to the behavior of resizing Playground -- there it happens only where it makes sense. I haven't found any applicable example directly in Roassal, but you can look into my smalltalkhub peteruhnak/roassal-contrib repo (same as we used before for moving stuff from dynacase) at DCRTResizable>>example On another note: I added methods for moving to RTLayoutTranslator for all sides, so you can probably move it to Roassal if it looks ok to you. Thanks, Peter

9 years, 11 months

2
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev