Moose-dev November 2012

moose-dev@list.inf.unibe.ch

23 participants
145 discussions

Issue 869 in moose-technology: Smalltalk code presentation does not populate the text port

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: chisvasi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7 New issue 869 by tu...(a)tudorgirba.com: Smalltalk code presentation does not populate the text port http://code.google.com/p/moose-technology/issues/detail?id=869 Typing in the code editor should populate the text port. The test in GLMSmalltalkCodeMorphicTest>>testExplicitAcceptDoesNotAffectTextPort captures the problem. See: http://ci.moosetechnology.org/job/moose-latest-dev/lastCompletedBuild/testR…

11 years, 4 months

Issue 873 in moose-technology: PPAllParsersBrowser does not remember the sample from the inspector

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: kurs....(a)gmail.com Labels: Type-Defect Priority-Medium Milestone-4.7 Component-PetitParser New issue 873 by tu...(a)tudorgirba.com: PPAllParsersBrowser does not remember the sample from the inspector http://code.google.com/p/moose-technology/issues/detail?id=873 In the old PPBrowser, when switching between different parsers, the sample code remains available. This behaviour should be provided by the PPAllParsersBrowser, too. Jan, could you commit your fix for this issue? :)

11 years, 4 months

Re: Issue 870 in moose-technology: ROFocusView focuses on the wrong spot

by moose-technology＠googlecode.com

Updates: Status: Started Comment #2 on issue 870 by alexandr...(a)gmail.com: ROFocusView focuses on the wrong spot http://code.google.com/p/moose-technology/issues/detail?id=870 This is not an easy problem to solve apparently. Try the following: -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= | node | node := view node: #a. view raw on: ROWindowResized do: [ :evt | ROFocusView new on: node view: view raw ]. -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= This seems to do the thing, but if you resize the window, the view always focuses on the node. If you do not want to focus on the node when you resize, we could do: -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= | node | node := view node: #a. view raw on: ROWindowResized doOnce: [ :evt | ROFocusView new on: node view: view raw ]. -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= But this does not work since the romorph is resized 4 times when you open the roassal glamour-based easel.

11 years, 4 months

invokedClasses removed?

by Fabrizio Perin

Hi, I have some tests failing cause invokedClasses is not part of FAMIXClass anymore. Is it a bug or it has been removed in purpose? Cheers, Fabrizio

11 years, 4 months

Issue 861 in moose-technology: The GTDebugger should ignore halt or test failure when setting the default selection

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: chisvasi...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-GlamorousToolkit Milestone-4.7 New issue 861 by tu...(a)tudorgirba.com: The GTDebugger should ignore halt or test failure when setting the default selection http://code.google.com/p/moose-technology/issues/detail?id=861 If we add a halt in the code, the intention is to get the debugger in the method where we added the halt, not in the code of the halt implementation. Similarly, when a test is failing, we want the selection to point to the test, not to the error code.

11 years, 4 months

Issue 862 in moose-technology: The GTDebugger should not break when there is an error obtaining the value of an attribute

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: chisvasi...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 862 by chisvasi...(a)gmail.com: The GTDebugger should not break when there is an error obtaining the value of an attribute http://code.google.com/p/moose-technology/issues/detail?id=862 To reproduce do the following steps: 1. Add the method: String>>breakDebugger | aVar | self do: [:c | 1=1 ifTrue: [ self halt ] ifFalse: [ aVar := 2 ] ]. 2. Execute: ['aString' breakDebugger] fork 3. In the debugger remove 'self halt' and recompile the method. 4. Select the top context This leads to an error as 'aVar' cannot be obtained from the context.

11 years, 4 months

deprecating GLMBrowserTemplate

by Tudor Girba

Hi, Starting with the original version of Glamour, we had the opportunity to define custom browsers through GLMBrowserTemplate. All you had to do was to override buildBrowser and construct your browser. For example: GlamorousBrowser>>buildBrowser browser := GLMFinder new. ... ^ browser I disliked this solution since a while. One reason was that embedding a browser into another one was inelegant because you had to say: a custom: GlamorousBrowser new browser instead of simply: a custom: GlamorousBrowser new So, now, we can achieve this by subclassing the browser from GLMCompositePresentation and overriding compose. And because the GLMCompositePresentation also contains the fluent API, you can script the browser in a fashion that is more consistent with the rest of the scripts. So, the example code would become: GlamorousBrowser>>compose self finder with: [:finder | ... ] The change might seem small, but to me it is significant. If we want to get people to program Moose, it must feel elegant to do so. And to reach this goal I think it is essential to strive to eliminate any unneeded concepts. Even if they are small. Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

11 years, 4 months

Issue 831 in moose-technology: Rossal problem with nested node translation to left of 0@0

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 831 by google....(a)ben.coman.com.au: Rossal problem with nested node translation to left of 0@0 http://code.google.com/p/moose-technology/issues/detail?id=831 The way negative translation is handled for nested elements is causing havoc as I was try to put some new tricks into ROCircleLayout. I now perceive this as a bug which I have distilled below. Review to the attached image #1 that was produced by the code listed below. I would expect that the three 'negative' squares would be spaced symmetrically to the three 'positive' squares. In attached image #2 element '-3' was moved to the left. Observe how the origin of element '-3' remains constant at 0@0 while the origin of elements '-2' and '-1' are modified as the left border is pushed further left. In effect, this behaviour appears to be the root cause of the 'non-symmetrical' behavior that is causing me grief. I believe that as element '-3' is dragged into the negative, the origin of '-3' should go negative leaving the origins of '-2' and -'1' unchanged. Let the parent node take care of the overall translation of its nested elements to keep the 'negative' elements in view. The overall visual effect of moving a node into a negative position should be unchanged, except that conceptually the 0@0 point will be drifting into the middle of the parent element rather than remaining fixed at the top left. By way of example, I believe the effect of this on ROCircleLayout>>doExecute would be to remove all references to the 'center' variable. This is with Roassal.283. Attachments: Roassal-problem-with-nested-node-translation#1.png 23.5 KB Roassal-problem-with-nested-node-translation#2.png 29.6 KB

11 years, 4 months

[Ann] 4.7 beta

by Tudor Girba

Hi, As a result of the successful Moose Dojo that took place on November 15-16, Moose 4.7 entered the beta state. Some of the outcomes of the Dojo are: - Cleaned a couple of hundred obsolete FAMIX navigation methods (by Robert and Nicolas) - Fixed the major bug when editing code (by Andrei and Stephan) - Fixed several other Glamour bugs (by Erwann) - Worked on improving the PPAllParsersBrowser (by Jan) - Got the GTDebugger to start to work with Bifrost (by Jorge and Andrei) - Got Reloader almost ready to work with Metacello and produce a reloadable version of the complete Moose (by Stephane and me). The 6 remaining issues are listed on the issue tracker: http://code.google.com/p/moose-technology/issues/list?q=milestone%3D4.7 Of these, the most important are: - http://code.google.com/p/moose-technology/issues/detail?id=869 (an unfortunate side effect of getting the code editing fast) - http://code.google.com/p/moose-technology/issues/detail?id=865 (we need to find the way to get the proper loading order of all packages) Anyone want to join efforts on these? Ideally, we should release somewhere at the beginning of December. Afterwards, we move to Pharo 2.0. Cheers, Doru -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

11 years, 4 months

Issue 859 in moose-technology: Polymorph UITheme>>exampleBasicControls MNU GTInspector class>>showIcons

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 859 by benjamin...(a)gmail.com: Polymorph UITheme>>exampleBasicControls MNU GTInspector class>>showIcons http://code.google.com/p/moose-technology/issues/detail?id=859 I was looking for Polymorph examples and UITheme class>>exampleBasicControls has a code snippet "self exampleBasicControls" in a comment to run itself. However a debug dialog appears with "MNU: GTInspector class>>showIcons".

11 years, 4 months

← Newer
1
...
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2012