29 Jun
2011
29 Jun
'11
9:31 a.m.
On Jun 28, 2011, at 17:31 , Tudor Girba wrote:
Do you think it is possible to particularize menu for kind of system ?
The idea is to have this menu for java software and not for smalltalk, as it is not
useful.
Nothing wrong, I am discovering these browsers :), and I am asking if someone uses them,
to avoid obsolete entries.
ok, I opened a bug entry.
When I load the same model from the same file (maybe the script does not load duplicated
entities ?) I have the same number of packages whereas it should be double.
I am not sure if the problem comes from entities that are not added or cache that is not
initialized. But, there is something :)
It is the first time I have that. And I am not sure it is reproducible. Maybe Morphic ?
ok, a new entry :)
Is it not a good idea to do this action just after the import ? Maybe there are some
strong implications ?
But, what does it do precisely ?
I think it put Smalltalk namespace for smalltalk source code.
I do not see for Java ? where java should not have a nil at this place.
Ok, that is a really nice functionality.
Does it work for Smalltalk ?
For example: Network-Core could create Network <- Core.
Ok, if it works, I do not understand the functionality :)
I hoped that when I selected the new directory, when I open a file browser to save or open
a new file, the browser open this particular directory. Which is useful when the directory
is not the same as the Moose directory.
Cheers,
Jannik
Hi,
Thanks. Comments inline.
On 28 Jun 2011, at 16:50, jannik.laval wrote:
Is it a good reason ? :)
Hi,
I am trying menus in Moose 4.6. I loaded Moose from MooseScript (method
createModelForMoose). And I tried all command in menus.
Here are my comments:
On a MooseModel, some commands are strange or does not work:
- browse:
- code with dependencies:
> why are there 2 times Smalltalk in the first pane ?
Because for some reason there are two namespaces created with the same name. Check
allNamespaces. > the visu seems strange and slow !
It is made for systems that have namespace hierarchies - like Java. So, for Smalltalk
it does not make sense. > is it used by someone ?
Yes.
> - code with design flow
> > unusable as it is slow
> is it used by someone ?
Yes. It is the same as above. It makes sense for Java systems.
> - code with namespace
> is it used by someone ?
Same as above.
> - code with package
> is it used by someone ?
Yes. This is the one that makes sense for Smalltalk. What is wrong with it? - export:
- export to fl
> does not work, there is a DNU. It seems that the notification does not work
We know. Cyrille posted the issue on the Pharo mailing list and it appears that we will
have a fix in Pharo for it.
- export to mse
> same problem than export to fl
Same as above.
- import file structure
> no progress bar.
> why is it loaded in the same mooseModel and change the model name ?
Every action that is in the contextual menu is performed on what you clicked. This is
always like that in Moose.
So, in this case, the import happens in the same model. Changing the name should not
happen, though. This is a bug. - import from fl / mse
> it imports, but I do not see what it does. There is no new model in the root. And
no new entities in my model.
There should be new entities in the model. Perhaps the browser does not refresh
properly. > after the import mse, the MooseBrowser
twinkled !!! (strange behavior) and the VM used 100% of my processor....
What did you import? What does twinkled mean? Did it finish in the end? - utilities
- bookmark entity: do nothing after asking for a name
It does create a new entry in the bookmarks group in the model. Again, perhaps the
browser does not refresh. If it's true, it's a bug. - ensure classes and namespaces: do nothing.
What is it ?
It simply patches a model to make sure there is no nil belongsTo - infer namespace parents based on names: do
nothing
It simply tries to infer namespace hierarchy when the importer does not do it. It makes
sense for Java systems. For example verveineJ exports a namespace with a name like
root::child::anotherchild. The mentioned script will create root <- child <-
anotherchild - set root folder does not work: I select a
folder, and it does not keep my selection.
Yes, it works. What do you mean?
Cheers,
Doru
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing should have the right to be different."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev