Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

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.

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

12 years, 5 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.

12 years, 5 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.

12 years, 5 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."

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

12 years, 5 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."

12 years, 5 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".

12 years, 5 months

Re: Issue 860 in moose-technology: Updatng a Glamour list disables the visible selection

by moose-technology＠googlecode.com

Updates: Summary: Updatng a Glamour list disables the visible selection Status: Fixed Labels: Milestone-4.7 Comment #2 on issue 860 by tu...(a)tudorgirba.com: Updatng a Glamour list disables the visible selection http://code.google.com/p/moose-technology/issues/detail?id=860 Fixed by Erwann.

12 years, 5 months

[ann] glamorous debugger (alpha)

by Tudor Girba

Hi, Over the last following days, Andrei Chis and me have worked on getting the Glamorous Debugger in a usable state (based on the original effort of Toon Verwaest): This debugger is part of the Glamorous Toolkit project, and it is based on Glamour (see the attached screenshots). You can find some details about it here: http://www.humane-assessment.com/blog/announcing-the-glamorous-debugger-alp… Some interesting characteristics: - It has an integrated inspector that shows all variables in one GTInspector with which you can browse in place all relevant variables - Code-wise, the debugger comes with an explicit model that relies neither on the old Debugger nor on the CodeHolder. The model is rather small and intelligible. In total, the entire code totals some 400 lines of code (at the moment). To put it into perspective, the Debugger class has 1096 lines of code (not counting the extra code used by it). Right now, we consider the code to be in a solid alpha, and we need more eyeballs and clicks to test it :). If you are interested in playing with it, you can either find it in the Moose image, or you can load it in Pharo 1.4 via: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) loadDevelopment Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

12 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