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.
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."
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Milestone-4.6 Component-Glamour
New issue 769 by tudor.gi...(a)gmail.com: Glamour should support drag and drop
http://code.google.com/p/moose-technology/issues/detail?id=769
Something like this:
a list
allowItemDrag: [:item :list | ... ];
itemDrag: [:item :list | ... ]
a list
allowDropOnItem: [:draggedObject :targetItem :list | ... ];
dropOnItem: [:draggedObject :targetItem :list | ... ]
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.7
New issue 809 by tudor.gi...(a)gmail.com: Glamour selection should happen
through an action
http://code.google.com/p/moose-technology/issues/detail?id=809
Right now, selecting an item in the user interface will directly populate
the #selection port. However, this is less than ideal because it does not
allow the developer to intervene in this process.
One possibility would be to introduce a selectionAction that is triggered
by the ui, and to provide the default behavior is simply setting the
#selection port.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-MooseCore Milestone-4.6
New issue 708 by tudor.gi...(a)gmail.com: Fame should accept comments both
for properties and for meta descriptions
http://code.google.com/p/moose-technology/issues/detail?id=708
Currently, the MSEComment: is used to define comments of a property.
SomeEntity>>someProperty
<MSEProperty: ...>
<MSEComment: 'comment'>
This is used by the MetaBrowser but not by Fame.
At the very least, we should add a means to add MSEComment: to the class
side for the overall class.
Hi!
Shouldn't the MooseModel>>resetMeta be accessible from the Utility menu? I think it was on some point, but not anymore apparently. Shall I can introduce it ?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I'm trying out Roassal to draw the entire revision graph of a Git repository.
Looking at the examples, the #tutorial>>step5LinearFillColor is broken (i.e., I got big red rectangle with a yellow diagonals).
Do anyone of you know a solution?
Cheers,
Roberto Minelli
We have been discussing here for long time that the meta-model approach
of Moose is not that much adapted to the problems of reverse engineering.
Because we need to model detailed informations on the programs being
modeled, Famix has many entities that are language specific.
Up to now we manage because Moose "core" deals with only two languages:
Java and Smalltalk
But if we wanted to deal with other languages C#, PHP, Python,
Java-script, Cobol, Pascal, Lisp, ... we would have to add entities
and/or constructs specific to each language and the tools would become
less and less generic.
More recently, it occurred to me that this is very similar to the kind
of issues one has to deal with in a statically typed language (Java is
evil :-) ).
So basically Famix introduced static typing in Moose.
If this analysis is correct, the questions would be:
- was it necessary to go that way? why?
- is there another way to do it? more in tune with the smalltalk way of
life?
nicolas