Hi Doru
How hard would it to implement this enhancement?
I see two paths, the dirty one and the clean one:
Dirty: make two panes stacked, one for the evaluator, the other a table widget with the history. The history is stored in the moose entity.
Clean: make a custom widget. Problem: where to store the history (if I browse to a parent entity and lose the finder pane of the entity, then I want my query history when coming back in the browser)
What do you think.
--
Simon
Hi all,
first of all: Thanks Doru for implementing the new features! They are
very useful to me.
Below is a screenshot of the AspectMaps UI that is using these
features. I have a bunch of questions related to this and I would be
very grateful if you could help me out. The code of the UI is also
below. Very big method, I know, but I did it this way to avoid
ambiguities in this mail.
Questions:
- How do I update the top mondrian panel using the new update
mechanism? I want it to redraw itself completely when some of the
buttons are pressed and on some of the menu actions of the aspects menu.
- The last 2 columns specify the metrics used in the polymetric view.
With a transmission I always get the last selections made, but I need
to know all selections made in that column so I can print it in the
selectionstatus text box. How is this possible? Also, if no selection
at all is made I would like to show that in the box (now the box is
removed).
- The last 3 columns actually do not use any input, but I specify them
with "transmit to: ; andShow:" Is there a cleaner way to do this?
The code is below:
----snip---
open
|browser colors colorizer|
"for aspect colors, both automatic assignment and manual selection in
menu"
colorizer := MOCircularColors new.
colors := OrderedCollection new.
1 to: 10 do: [:num| colors add: colorizer nextColor].
browser := GLMTabulator new.
browser title: 'AspectMaps Window'.
browser row: #mpanel span: 3.
browser row:[:r|
r column: #models span:2 ;
column: #aspectsel span: 2;
column: [:c| c row: #buttons span: 4. c row: #selectionstatus.]span:
2;
column: #hprop;
column: #wprop] span: 2.
browser transmit to: #mpanel; from: #models; andShow: [:a |
a mondrian painting: [:view :model|
model allNamespaces do: [:ns| ns currentShapeFor: view
withProperties: self].
view gridLayout.]].
browser transmit to: #models; andShow: [:a |
a stackedVerticallyArrangement.
a tree title: 'Available projects';
children: [:model | (SortedCollection sortBlock: [:x :y | x name <=
y name]) addAll: model allNamespaces asOrderedCollection; yourself ];
act: [:tree | tree selection inspect ] on: $i entitled: 'Inspect';
format: [:model | (model name) copyReplaceAll: '::' with:'.' ]].
browser transmit to: #aspectsel; from: #models transformed: [:model |
|topmodel|
topmodel := model mooseModel = MooseModel root ifTrue: [model]
ifFalse:[model mooseModel].
topmodel allAspects do:[:asp | asp color ifNil: [asp color:
colorizer nextColor]].
topmodel allAspects ];
andShow: [:a|
a stackedVerticallyArrangement.
a tree title: 'Aspects in Project';
format: [:asp | Text string: ((asp show ifTrue: ['(ON) '] ifFalse:
['(OFF) ']),
asp name) attribute: (TextColor color: asp color).];
act: [:tree | tree inspect ] on: $i entitled: 'Inspect (i)';
act: [:tree | |asp ann|
asp := tree selection. asp show: (asp show not).
tree update.] on: $t entitled: 'Toggle On/Off (t)';
actions: [:tree | colors collect: [:col | GLMAction new title: col
asString; action: [tree selection color: col. tree update]; category:
'Color']]].
browser transmit to: #buttons; andShow: [:a |
a actionList
act: [:entity | entity inspect] entitled: 'Vizualize';
act: [:entity | entity inspect] entitled: 'Max Zoom Out';
act: [:entity | entity inspect] entitled: 'Max Zoom In';
act: [:entity | entity inspect] entitled: 'Multiple Aspects Zoom';
act: [:entity | entity inspect] entitled: 'Zoom by Query'.
].
browser transmit to: #hprop; andShow: [:a |
a accordionArrangement.
a list title: 'Classes Height'; display: self cprops;
allowDeselection.
a list title: 'Aspects Height'; display: self aprops;
allowDeselection.
a list title: 'Methods Height'; display: self mprops;
allowDeselection.
].
browser transmit to: #wprop; andShow: [:a |
a accordionArrangement.
a list title: 'Classes Width'; display: self cprops; allowDeselection.
a list title: 'Aspects Width'; display: self aprops; allowDeselection.
a list title: 'Methods Width'; display: self mprops; allowDeselection.
].
browser transmit to: #selectionstatus; from: #hprop; from: #wprop;
andShow: [:a |
a text display: [:x :y| x asString , ' ', y asString]; allowNil].
browser openOn: MooseModel root allModels asOrderedCollection
----snip---
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi,
I am happy to announce a new feature in Glamour in the form of the
Accumulator browser. This browser is an implicit one that just takes
the input entity and creates a new pane for it. It is called an
Accumulator, because it accumulates panes as you provide a new input.
These panes are then displayed as tabs.
A complementary feature is in a new way bundle transmissions are
passed around. You can pass it like before with andShow:, or you can
do it with andShowWithoutOverride:. It's not a very nice name, but the
idea is that it only transmits the presentation if the same
presentations were not already found in the target pane.
Using Accumulator you can now emulate browsers that behave like the
Eclipse central pane. An example can be found here:
GLMBasicExamples new accumulator openOn: 42.
This feature is now also used in the MooseFinder and MoosePanel. If
you open the Panel and select a model, you open it in a new tab. From
the Finder, if you double click on an item in a list you get it in a
new tab.
I hope you like it.
Cheers,
Doru
--
www.tudorgirba.com
"The coherence of a trip is given by the clearness of the goal."
A significant slowdown may be noticed when compared with the previous
glamourous report (sent on October 23). Details at the end of the amil.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Report produced on 2010-01-16T15:19:06+00:00
------------------
Opening Browser Benchmark:
15 openings => 2620 ms
------------------
------------------
Selecting Item in Browser Benchmark
100 size and selections => 2569 ms
200 size and selections => 4359 ms
300 size and selections => 6912 ms
400 size and selections => 8298 ms
500 size and selections => 10414 ms
600 size and selections => 12462 ms
700 size and selections => 14019 ms
800 size and selections => 16123 ms
900 size and selections => 19234 ms
1000 size and selections => 19984 ms
1500 size and selections => 30812 ms
2000 size and selections => 45497 ms
------------------
------------------
Selecting in finder item Benchmark
1 size and selections => 166 ms
5 size and selections => 897 ms
10 size and selections => 1949 ms
15 size and selections => 2968 ms
20 size and selections => 4008 ms
25 size and selections => 5112 ms
30 size and selections => 11714 ms
35 size and selections => 7686 ms
40 size and selections => 8963 ms
45 size and selections => 10428 ms
50 size and selections => 12471 ms
------------------
50.66 % of methods are covered from unit tests
Progress from last time: +17.19 %
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From the report generated on Oct 23, we had:
Selecting Item Benchmark:
2000 size and selections => 2729 ms
Selecting in finder item Benchmark:
50 size and selections => 1881 ms
The new version is one magnitude slower.
However, opening a browser is slightly faster. The first health report
indicated:
15 openings => 3622 ms
Cheers,
Alexandre
As the regular sanity check, here is the mondrian health report for
this month.
I created a squeaksource HealthReportProducer. I have in mind plenty
of improvements for it (e.g., check of architectural rules, speed
progress measurement). I will slowly work on this...
Edges got slower to render. I need to dive a bit into the recent
changes to understand why.
Report produced on 2010-01-16T14:49:26+00:00
Benchmark ManyNode (simple rendering of nodes) :
100 nodes => 15 ms
200 nodes => 53 ms
300 nodes => 113 ms
400 nodes => 201 ms
500 nodes => 345 ms
600 nodes => 457 ms
700 nodes => 760 ms
800 nodes => 812 ms
900 nodes => 1137 ms
1000 nodes => 1243 ms
1600 nodes => 3855 ms
Benchmark ManyEdges (simple rendering of edges) :
10 edges => 2 ms
20 edges => 7 ms
30 edges => 43 ms
40 edges => 33 ms
50 edges => 54 ms
60 edges => 139 ms
70 edges => 146 ms
80 edges => 196 ms
90 edges => 314 ms
100 edges => 385 ms
200 edges => 5565 ms
300 edges => 40862 ms
55.65 % of methods are covered by unit tests
Progress from last time: +0.57 %
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
The implementation of the Moose Finder from the Object>>inMoose
started to be way too large to, so I moved it into an own class
MooseFinder.
Cheers,
Doru
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot
be done."
What do you think of deleting old packages which are completely useless, even for historical purposes. Some are actually from early attempt to port Moose but we have moved on since.
A few examples:
Moose-Installer
Smart-Collections
Monticello
SLICE-*
Merlin (has its own project now)
TestWizard (now part of Merlin?)
MooseGlamourBrowser (early attempt)
Moose-UI (early attempt)
Moose-Test-PackageBlueprint (old, duplication)
PackageBlueprintOld
Moose-PackageBlueprint (deprecated)
Moose-NewBlueprint (deprecated)
Moose-PB* (deprecated)
Moose-NP* (deprecated)
Moose-LANTests (old stuff)
Moose-Importer-Tests (old stuff)
I dont want to delete some deprecated packages which still have a lot of versions, might be interesting for historical purposes.
Browsing the Moose repository from MC often feels sluggish : I suspect this is because of the high number of files. Maybe one day we should split between a Moose project and a Famix project.
--
Simon
Hi,
Glamour is in a usable state again.
The one thing is not working correctly is the update of the overall
browser from inside the browser. For example, the mechanism in the
MooseModel browseMeta to select a property and then trigger "Focus"
from the contextual menu does not update the properties pane again.
Things will continue to move in the next period, but it already looks
pretty much Ok. Here are a couple of major changes:
1. A pane now can control the rendering of multiple presentations
through a CompositePresentation. You can now have different
arrangements: tabbed, accordion or stacked. You can find an example at:
GLMBasicExamples new differentComposites openOn: (1 to: 100)
2. You can specify titles for a composite and this gets rendered as a
groupbox
3. New syntax. To control the composite I introduced a new syntax.
- "browser showOn: ; from: ; using: [ browser list]" -> "browser
transmit from: ; to: ; andShow: [ :a | a list ]"
- "browser sendTo: from:" -> "browser transmit from: ; to:"
4. Simple transmissions and bundle transmissions can have multiple
origins and can define transformations per origin port. For example
you can have:
browser transmit from: #one ; from: #two transformed: [:x | ...] ; to:
#three.
5. Presentations can now update using a basic mechanism (first
implemented by Jorge and Philipp). For example:
a list updateYourselfOn: SomeAnnouncement from: [:entity | some
announcer];
The only catch here is that the entity object should point to the
objects that gets changed. You can also force an update explicitly
from an action:
a list act: [:presentation | presentation update] entitled: 'some
action'.
6. When updating a presentation, it might be that the selection from
the old presentation does not make sense in the new context. To enable
a checking you can now specify that you want validation for each
change in the ports (in particular for selection). For example:
a list shouldValidate: true
7. Finder can now properly embed a browser. This is actually pretty
neat :)
8. Finder now remembers the title of the last active presentation and
it will favor this one in the new tab
Please have a look and let me know if you encounter problems.
Cheers,
Doru
--
www.tudorgirba.com
"The coherence of a trip is given by the clearness of the goal."
Hi Alex,
I am trying to debug the problem of embedding Mondrian in Glamour and
I have a question.
Why exactly does Mondrian need to know the window to update? Why is it
not enough to just know the Canvas morph?
Cheers,
Doru
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of
problem understanding."
Hi,
I noticed that isPackage, isPrivate, isProtected were removed from
FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods
should be in Famix-Extensions, but they should not be removed.
Also, isFinal was moved in Famix-Java. This is a Java specific,
because it has a meaning also for C++ programs where isFinal is
everything that is not explicitly defined as virtual.
Did I miss something?
In general, we have to be more careful with changes at such core
levels :)
Cheers,
Doru
--
www.tudorgirba.com
"One cannot do more than one can do."
