Suggestions

- You should be able to view multiple models at once like in a source-file. It's a little bit annoying to open a lot of windows with a single structure/editor/etc definition in it instead of looking at all of them in one window.

- We really need some documentation for the java classes (aspect methods). It's impossible to do something non-trivial right now.

0
4 comments

- We really need some documentation for the java

classes (aspect methods). It's impossible to do

something non-trivial right now.

Unfortunately, no such documentations exists :-(

Anyway it isn't worth to learn something that eventually mustdie.

What if in next MPS build we include java sources of all "aspects"?

You will able to navigate from models to java and backward and learn aspect methods by example.

Does it make sense?

Igor

0

- You should be able to view multiple models at once

like in a source-file. It's a little bit annoying to

open a lot of windows with a single

structure/editor/etc definition in it instead of

looking at all of them in one window.

Our current workspace is very primitive, and we didn't yet approached to design of really suitable, language-centric workspace.

Obviously, there should be many perspectives for the same project entities.

Does somebody have suggestions / references ?

Igor

0

Ok, thats true.

But it means, that there should be some kind of query language very soon. That shouldn't be that difficult if it possible to use MPS to define this language which is then rewritten to java aspect methods (but I know the difficulties of bootstrapping such a system, and I don't know how far you've been in this process right now).

Will it be possible to change the MPS 'base' (like editor-language, query-language etc.) in MPS itself? If everybody can add it's own features to MPS it will grow very fast then, because the good parts of it could be ported back into the base system.

0

I don't know enough about how MPS works right now, but I think there should be the possiblity to define as many editors as one wishes to each structure type.

The editor which is choosen to display something then depends on a value which is defined per editor pane and can overridden in each editor to set the display of the child elements.

Also folding each element should be possible, maybe even some kind of 'global folding' which hides details of a specific type of structure for each instance of this type.   

Another idee is something like 'tree reordering':

The display of structures like

A

  B

A

  C

could be displayed like

B

  A

C

  A

So the user can reorder the view of the project (or something else) from 'each project (structure, editor, generator, ...)' to 'each structure (project), each editor (project), ...'. This combined with folding gives many possible views depending on what and how you're working on.

Some step further you could use the query language to create some subset of a tree and reorder it to display only specific parts of a project.

And you should of course be able to store customized views to recall them later.

0

Please sign in to leave a comment.