Filter the list of packages and types provided by txtUML wizards

[djnemeth]

Our Generate C++ code from txtUML and Generate diagrams from txtUML wizards allow users to browse the project and model package they wish to use as a source, after which they can also select deployment configurations and diagram descriptions, respectively.

It's a bit inconvenient that the "model" browser lists all packages within the selected project and "deployment configuration" / "diagram description" browsers are just type selection dialogs showing all classes and interfaces available in the workspace.

It would be neat if

• model browsers listed only model packages defined in the selected project,
• deployment configuration browsers showed only configurations and
• diagram description browsers listed only diagram descriptions.

Please note that in the last two cases, displaying types which were defined in the selected project only would be too strict. For example, I believe it's perfectly acceptable to isolate diagram descriptions from a complex model in a separate project.

[djnemeth]

As suggested in #180, it might be more user-friendly to provide actual browser dialogs (i.e. something that lists the available options) for diagram descriptions and deployment configurations, instead of the currently implemented search dialogs.

My concerns are, however, that the list of available descriptions/configurations could grow too large in case of complex workspaces, as we cannot easily tell which model they belong to (apart from state machine diagrams). This, of course, holds only if we look for said definitions outside the project of the source model as well, which I think we should, see the last paragraph of my previous comment.

@dobreffandras and @kmozsi, what do you think?

[dobreffandras]

Yes, you're right so for selecting deployment configurations / diagram descriptions the FilteredTypesSelectionDialog is not the way to go.

I see your point on the separation of the model itself and... actually all other things like Visualization, Cppgen, UI or other externals. The question is, what is the reason of placing them in a separate project? Or what is the benefit of that? Anyway I understand your concern that some day a user may want to place his descriptions in another project and that would be sad if the eclipse UI would be the blockage.

The best solution would be to list only the ones that refer to the given model from the workspace. I has a hacky way to do, but I don't think we want to do that. Another solution came to my mind, namely we could list all descriptions from the workspace but grouped by project. In my opinion it would be a custom implementation of ElementTreeSelectionDialog.

But the most reasonable solution to this problem (at least for diagram descriptions) is our old (but gold :D :P ) idea of persisting the set of the to be visualized diagram descriptions in a "configuration" (or such like that) file. With this solution the visualization process would be as userfriendly as can*. I mean a "right click -> visualize" menu entry on the project could be implemented. Furthermore these files can be version controlled so every user will se the same diagrams. In this case the currently known Visualization Wizard would have the only role of editing these files.

@devaigergely81 what's your opinion?

*except the dream of roundtrip editing of the models

[kmozsi]

As we have discussed, it would be more user-friendly to select deployment configurations and diagram descriptions on a browser dialog than on the currently used type selection dialog.

As a first step, a filtered search should be implemented, so the user will be able to choose only from deployment configurations/diagram descriptions.

Then, it would be convenient to let the user select more than one items from the list of diagram descriptions (e.g. on a slush bucket (twin box) dialog that has a left and a right field, the left one contains the available descriptions, the right one contains the choosen descriptions.) Practically, we could group the descriptions by projects in the left field.

A context menu is needed to the package/project explorer: if the user clicks on a diagram description with right button, and chooses 'Visualize', the mentioned slush bucket dialog should appear with this selected description in the right column.

These visualization configurations could be automatically persistable by the wizard.

[dobreffandras]

I close this issue as it fulfills the initial requirements. About the configuration files we'll open a new issue when becomes a serious 'must to have".