MiDependencyBrowserModel>>followAction
	(self accept: toSelect) ifFalse: [ ^ self ].
	(toSelect isOfType: MooseGroup)
		ifTrue: [ self model entities: toSelect ]
		ifFalse: [ self model entities: {toSelect} ].
[...]

in MiDependencyBrowserModel>>accept: we check that the selection is a collection, but later in followAction we check for a MooseGroup

MooseModels are MooseAbstractGroups so they are treated as a single entity :-(

Several tags contain only one class (Command, FameBrowser, Icons, ...),

and some tags are plain wrong, for example 'Tests' for AbstractBrowserMode and subclasses

From the addNewQuery option would propose a list of current result, allow to select some and apply

From resultOfCurrentQueryPane, selection of entities + a right-click should allow to create the same query

The 'model' role seems to be implemented in MiDependencyVisualization ...

If an entity is contained in another.
It is then present as itself and as an entity contained in the other.

Update query creation browser according to a query:

• from the displayed code when modified
• from an existing query, to modify it

So when there is an update it is displayed in the top of the window

put a message in the visualization (instead of the graph) ?

So we can remove all the log

tried with https://github.com/NicolasAnquetil/OpenStackInMoose.git

There is for example relationships between ResourceType and Feature

or may be the default message is not clear enough

Currently, when select something in a browser, the application is notified:
self application globallySelected: <selection>
The application logs this:
self logger globallySelect: <selection>
The logger records the entity-ies
MiSelectedEntityLog new AND "activates" it, which propagates the selection to all browsers.

I believe the activation should be done by the application itself

Why ?
It would allow to come back in history and reset all browsers to a previous state

PB: Currently, when importing mse, MoosePanel try to search entities read in the mse file in a default mooseModel. As each famixMetaModel has its own model now, the importing fell because entities are not found.
S: MooseModel should allow the user to choose one of the existing models in the image

so forget the #beChildOf:

at least from the displayed name (window, menu), no need to change the class names

... because there is no last select entity (no models, logger empty, ...)

MiAbstractBrowser class >> #runMe
	<script>
	self new
		openWithSpec;
		"open with the last select entity"
		selectEntity: MiApplication current logger logs last entity

it would take the resultOfCurrentQuery and reset the "root" of the QueryBrowser with this result.
Kind-a opening a new QueryBrowser on the current result (but in the same browser)
Should probably force a "propagate" to the whole Midas

the two names are too similar and it's hard to guess what they do.

MooseModelBrowser should allow to browse Models, i.e. what MooseRootBrowser currently does

and the current MooseModelBrowser could may be merged with the Properties browser ?
(other issue)
For now, I propose to rename it ModelContent browser

clicking repeatedly on the (initial) "Model" query changes the content of this pane, actually the order of the "entities" listed.
This is unsettling

Note: ALWAYS order displayed lists. The actual order may not matter but make sure there is one

For when we add on the fly new models. Currently the option is to close the browser and open a new one

Look each case independently because it could lead to "bootstrap" issues :
initializePresenter would be called before model initialization and the presenter might need the model ...

Two options:

• Explicitly: with an 'un-highlight' button
• Implicitely: when the browser behavior is changed to 'Follow'

following on #38, in ImportModel window, the (drop down) list of metamodels could give the name and a short description

fresh default Midas distribution.
called from FQQueriesBrowserPresenter class >> #runMe

So that one understands what depends on what

Lines could be used for reciprocal dependencies ?

Talking of the MooseModel browser at the time of this writing (see issue #39)

MooseModel browser and MooseProperties browser seem like two instances of a Moose "inspector" that show the details (properties,relationships) of the current entity.

Couldn't they be merged?
A bit like a pane of the MoosePanel, except that I would put two panes (vertical layout) for properties and relationships

We should add a command in the rootmodel browser that allows one to set its root folder

MiSelectedEntityLog is just an entry in the log ...

Having to right click on a query to add a new one may not be intuitive (it is good HCI politics to have several ways to do any given action)

(instead of adding 1 button, could add a button bar with the whole context menu)

Browsers should be able to say that they cannot do Highlight and/or Follow
In this case, the respective radio buttons would be disabled

Proposed API in MiAbstractBrowser:
cannotFollow / canFollow / cannotHighlight / canHighlight

same goes for Propagate ?

Breadcrumbs bar available in QueryCreation window could be available in QueryBrowser and showing path of current query

We should add a title to the log browser

in MiModelRootBrowser>>initializePresenters we have:

initializePresenters
[...]
	modelPresenter
		whenSelectionChangedDo: [ :selected | 
			model selected: selected selectedItem.
			self application globallySelect: selected selectedItem ]

I believe the second instruction (self application ...) should be in the model, not the SpecPresenter.
But this means accessing the application from the model which kind of implies all models of all MiBrowsers should have it, whereas Spec places it in the presenter (this is an instance variable of SpPresenter).

Having application in the model also suggests we need an abstract class of models to generalize this.

So one can remove some useless entry

We can see it in the logger.
When we propagate something multiple entries appear in the logger.

Very few classes commented :-(

MiLogger in Midas-Logger
MiLogBrowser in Midas-Browser

None of them has a "Spec description" (initializePresenter , defaultSpec)

The default behavior was initially intended that any selection in any browser automatically propagates to all opened browsers. This is a bit similar to MoosePanel where any selection automatically opens a new pane (propagation)

This can be fine-tuned by 'frozing' browsers to ignore this propagation

One could imagine not wanting to always propagate all actions, but then 'propagate' should be a checkbox ...

Modify selected query according to accepted modifications in the code panel.

currently, it shows for example:
FamixModel, FAMIXModel, FAMIXMooseModel, ..., FamixTest1Model, ...
let's simplify !