Bugzilla – Full Text Bug Listing
| Summary: | [Model Explorer] It is impossible to see the additional resources | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | JBregnias <julien.bregnias.ext> |
| Component: | Views | Assignee: | Camille Letavernier <cletavernier> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cletavernier, give.a.damus, papyrus-bugs, ronan.barrett, ronan.barrett, toni.siljamaki |
| Version: | 0.10.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 360092, 413061 | ||
|
Description
JBregnias
What do you mean by "additional resources"? Additional resources are libraries Ok. But if I use a library resource I can see it in the Model Explorer as it is a Package Import. Not sure I see a problem. Actually, Package Import has a specific semantic in UML. It should be possible to reference external elements directly. In this case, this makes sense to be able to display additional resources. The different between a Package Import and a direct reference is the same as in java: import java.util.*; //Package Import List myList = new java.util.LinkedList<Object>(); //Direct reference Yep I get it but how can I do a direct reference to a type without having imported the types? For example setting a property type. I can only see types from my model and imported models. Related to the bug on having many models open in the Model Explorer. If we had this bug/fetaure then we could have direct references without imports. Or if we could load a resource in the Model Explorer we could do this. The latter is missing from Papyrus or? > I can only see types from my model and imported models.
That's exactly the point: you can't, until this task is actually fixed :)
BTW, there is a "Load resource..." option available in Papyrus (Only in Luna, I think; it was disabled in Kepler), to skip the "Import..." thing. We'd also need an option in the "Import..." menu to only load the resource (Without actually creating a "Package import" element)
The "many models" feature is slightly different (At least in terms of implementation), because different models are located in different Editors/EditingDomain/ResourceSets (The same physical resource can be loaded twice in memory, then the in-memory instances are not synchronized until one of them is actually saved).
In this specific case, all libraries are loaded in the same Resource set, so it's much easier to handle.
Ok great! Then I think this is a very important bug to fix :) Initial contribution in febcdd8 -> 88ab17b on master
All loaded resources now appear in the Model Explorer. The following resources are currently excluded:
* Model fragments ("Submodel units")
* Profiles, when the main resource is not a Profile
* UML Metamodel
* Ecore Metamodel
(This filter is arbitrary and will change depending on users feedback)
This also applies to Model browsers opened in dialogs from e.g. the Properties view (Type a property...)
I've also fixed a few bugs which are not directly related, but have been highlighted by this feature:
- Some property testers used to load the profiles into the current resource set, to determine whether the profile is applied. The test is now based on the profile's qualified name.
- The import package/apply profile actions used to load all libraries/profiles into the current resource set. They are now loaded in a separate, shared resource set, and reloaded into the current resource set only when they are actually applied
This also solves Bug 360092, Bug 413061
Commit 48a3e9e: - Fix Memory Leaks, and improve the Resource set listener Commit 0cfbbcb: - Add a "Load model" action in the "Import Package" dialog. This action is enabled by default (Instead of "Import", which creates a PackageImport element) Pushed to master Hi, Camille, I've merged these changes from master to my branch for bug 323802 and get some interesting results. I can create diagrams for read-only library models: 1. Create a new model A in the workspace, from the template that imports the UML Primitive Types. 2. The primitive types library model now shows up in the top level of the Model Explorer (nice). 3. Right-click on the primitive types model and create a class diagram. 4. Counter-intuitively, this works and does not violate any read-only constraints. Will users find this surprising? Is it correct? The reason why this works is that the diagram, as any other would be, is created in the notation resource of the model that I'm editing, namely A, which references the primitive types library. There is no read-only constraint on that notation resource, but the result is odd because it *looks* like the diagram is added to the library model. In fact, it isn't, and if I close and re-open A, the diagram is still there (as expected, because it is stored in A.notation in the workspace). Hi Christian, At some point, we'll need to be able to import diagrams as well as semantic models. When this happens, we'll also need to be able to create diagrams either in the selected element (e.g. Library), or in the importing element (actual Model) I was actually expecting this behavior, and I may do something about it when refactoring the DI model (And Page Manager). I think we'd need a few additional things: 1) Ask the user where the diagram should be created, when he's creating a diagram for an imported model 2) Show the actual location of the diagram in the properties view 3) Allow the user to move (physically) the diagram (to another resource) Laurent's "viewpoint" branch, which has not been merged, already adds some support for moving diagrams (logically, I think, i.e. where they "appear" in the Model Explorer, but not physically, i.e. in which resource they are serialized). The issue is, I think, the same with controlled models. When the model is controlled, the diagrams are moved to the new notation resources. However, when new diagrams are created in controlled elements, I think they appear in the root notation model. Anyway, I'll be working on these features for the next two weeks (Until M6). Hi, I have some issues with this prototype. #1 There is no use in having the PrimitiveType model loaded when I already have access to it via the PackageImport. The Model Explorer should be as clutterless as possible. The objective of this item was to allow us to access resource which were *not* PackageImported already. #2 (same question as Christian) Why am I allowed to add Diagrams to the read-only resources, in this case the PrimitiveTypes library? This is very confusing. The diagram lives in the PrimitiveTypes library but it is clearly stored somewhere else in the resource using this library. #3 What is the use-case for importing model diagrams? I don't think I have seen that before. #4 I am able to create a package import inside the read-only PrimitiveTypes library. Papyrus does not complain but they logs a nasty error upon reopening the model, and the package import has gone. The error is as follows: org.eclipse.papyrus.infra.core.services.ServiceMultiException: Multiple exceptions ----- exceptions : ---------- ServiceDescriptor [key=org.eclipse.papyrus.infra.core.resource.ModelSet, serviceClassname=org.eclipse.papyrus.infra.services.resourceloading.OnDemandLoadingModelSetServiceFactory, serviceStartKind=STARTUP, priority=5] : ----------------------------- at org.eclipse.papyrus.infra.core.services.ServicesRegistry.disposeRegistry(ServicesRegistry.java:853) at org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.dispose(CoreMultiDiagramEditor.java:775) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.invalidate(CompatibilityPart.java:222) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.destroy(CompatibilityPart.java:370) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:877) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:857) at org.eclipse.e4.core.internal.di.InjectorImpl.uninject(InjectorImpl.java:179) at org.eclipse.e4.core.internal.di.Requestor.uninject(Requestor.java:142) at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:82) at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:107) at org.eclipse.e4.core.internal.contexts.EclipseContext.removeListenersTo(EclipseContext.java:460) at org.eclipse.e4.core.contexts.ContextInjectionFactory.uninject(ContextInjectionFactory.java:144) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeRemoveGui(PartRenderingEngine.java:917) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$3(PartRenderingEngine.java:837) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$8.run(PartRenderingEngine.java:832) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.removeGui(PartRenderingEngine.java:817) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$1.handleEvent(PartRenderingEngine.java:154) at org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:41) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:185) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4559) at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:208) at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38) at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:80) at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:58) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(UIElementImpl.java:290) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.hidePart(PartServiceImpl.java:1218) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.hidePart(PartServiceImpl.java:1153) at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.closePart(StackRenderer.java:1192) at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.access$3(StackRenderer.java:1174) at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer$12.close(StackRenderer.java:1068) at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:1874) at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:288) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4423) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3771) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3391) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1122) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1006) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:146) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:615) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:566) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:125) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) Caused by: java.util.ConcurrentModificationException at org.eclipse.emf.common.util.AbstractEList$EIterator.checkModCount(AbstractEList.java:758) at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:706) at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:692) at org.eclipse.uml2.uml.internal.operations.ElementOperations.getAppliedStereotypes(ElementOperations.java:329) at org.eclipse.uml2.uml.internal.impl.ElementImpl.getAppliedStereotypes(ElementImpl.java:246) at org.eclipse.uml2.uml.internal.operations.ElementOperations.getAppliedStereotype(ElementOperations.java:358) at org.eclipse.uml2.uml.internal.impl.ElementImpl.getAppliedStereotype(ElementImpl.java:259) at org.eclipse.uml2.uml.internal.operations.ClassOperations.isMetaclass(ClassOperations.java:187) at org.eclipse.uml2.uml.internal.impl.ClassImpl.isMetaclass(ClassImpl.java:1079) at org.eclipse.uml2.uml.internal.operations.ClassOperations.getExtensions(ClassOperations.java:116) at org.eclipse.uml2.uml.internal.impl.ClassImpl.getExtensions(ClassImpl.java:841) at org.eclipse.uml2.uml.internal.impl.ClassImpl.eGet(ClassImpl.java:1365) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1011) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSetting(BasicEObjectImpl.java:1596) at org.eclipse.emf.ecore.util.ECrossReferenceAdapter.getInverseReferences(ECrossReferenceAdapter.java:349) at org.eclipse.papyrus.infra.core.utils.EMFHelper.getUsages(EMFHelper.java:59) at org.eclipse.papyrus.infra.core.resource.ProxyModificationTrackingAdapter.setReferencingResourcesAsModified(ProxyModificationTrackingAdapter.java:125) at org.eclipse.papyrus.infra.core.resource.ProxyModificationTrackingAdapter.notifyChanged(ProxyModificationTrackingAdapter.java:112) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.dispatchNotification(NotifyingListImpl.java:261) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.clear(NotifyingListImpl.java:1090) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.doUnload(ResourceImpl.java:1641) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doUnload(XMLResourceImpl.java:681) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.unload(ResourceImpl.java:1663) at org.eclipse.papyrus.infra.core.resource.additional.AdditionalResourcesModel.unload(AdditionalResourcesModel.java:115) at org.eclipse.papyrus.infra.core.resource.ModelSet.unload(ModelSet.java:898) at org.eclipse.papyrus.infra.services.resourceloading.OnDemandLoadingModelSet.unload(OnDemandLoadingModelSet.java:57) at org.eclipse.papyrus.infra.services.resourceloading.OnDemandLoadingModelSetServiceFactory.disposeService(OnDemandLoadingModelSetServiceFactory.java:51) at org.eclipse.papyrus.infra.core.services.internal.ServiceFactoryEntry.disposeService(ServiceFactoryEntry.java:169) at org.eclipse.papyrus.infra.core.services.internal.StartStartupEntry.disposeService(StartStartupEntry.java:80) at org.eclipse.papyrus.infra.core.services.ServicesRegistry.disposeServices(ServicesRegistry.java:993) at org.eclipse.papyrus.infra.core.services.ServicesRegistry.disposeRegistry(ServicesRegistry.java:854) ... 74 more Hi Ronan, > #1 There is no use in having the PrimitiveType model loaded when I already have access to it via the PackageImport. The Model Explorer should be as clutterless as possible. The objective of this item was to allow us to access resource which were not PackageImported already. I disagree here. The Package should not appear in the "Package Import" element; only at the root of the model. PackageImports can be located basically anywhere in the model and can be hard to locate. Moreover, we should avoid confusing the users with this element. Because of the legacy implementation in Papyrus, many users believe that the "ImportPackage" element is required for using elements from another model. Now that the PackageImport element is not mandatory anymore, we should make it as optional as possible, i.e.: - Do not display the package contents under the PackageImport element (Unless the "Advanced Model Explorer" is activated) - Display the imported models/libraries at the root of the ModelExplorer, to avoid a false idea of containment or scoping (Even if the model is made available through a sub-sub-sub-sub-package of the model via a PackageImport, it is actually available for all elements in the Model; only Namespaces are actually affected by the "PackageImport" element) > #2 (same question as Christian) Why am I allowed to add Diagrams to the read-only resources, in this case the PrimitiveTypes library? This is very confusing. The diagram lives in the PrimitiveTypes library but it is clearly stored somewhere else in the resource using this library. In some cases, it may make sense to create a diagram for an imported library, to help visualizing it. And sometimes, you don't want (or can't) modify this imported library directly. But I definitely need to add a warning/user choice/whatever to reduce confusion. > #3 What is the use-case for importing model diagrams? I don't think I have seen that before. If a library is shipped with a set of diagrams (That's the initial point of UML: diagrams :) ), library clients cannot see them in any way today. That's the same idea as providing libraries with sources in programming languages. Moreover, it is not about "importing", it is about "loading" (in read-only mode). > #4 I am able to create a package import inside the read-only PrimitiveTypes library. Papyrus does not complain but they logs a nasty error upon reopening the model, and the package import has gone. The error is as follows: Read-Only mode doesn't really exist in Papyrus today. Currently, it's basically just a graphical hint, with many bad side effects and bugs. Christian's currently working on that in Bug 323802: Papyrus shall provide a read only mode. Once this is finished (soon), you won't experience such issues anymore. Comment on #2: This is (in principle) same problem as in Bug 405586 = should not be allowed. If a user need to create a diagram for an imported library it must be created somewhere else, not in the imported library. Comment on #3: To create a hyperlink to a diagram in "current" model is quite straight forward. The hyperlink can be created on any element, then click to open the diagram. However... Products are typically built from multiple model. We have use cases where users from day 1 needed to create a hyperlink to a diagram in a different model. (to be able to click to open it) To do that one must first load the .notation file of that model into a diagram of the model in which you like to put your hyperlink. Then the pocedure for creating the hyperlink to a diagram in a different model is different from creating a hyperlink to a diagram in the current model. This is quite complicated and confusing for users. If a model has been imported its diagrams should be visible in Model Explorer right away, which is what users expect when working at the model level. Related to this are the reported lazy-loading bugs. A diagram should not be loaded into memory until it is actually opened, and only the opened diagram. Hi Camille, - #1 I don't see why the contents of the package import should not be visible under the package import. Other tools do this and it makes sense to me. The key issue is that it must not appear twice as this is just clutter. In the case when the type are from another model and there is no package import then we should see the other model loaded at the root level. - #2/#3 I agree a diagram could be provided with a library but that does not mean a user should be allowed, or would want to, create one themselves. I don't see the use-case for the latter. The key aspect of libraries is type re-use. - #4 Ok great! > - #1 I don't see why the contents of the package import should not be visible under the package import. Other tools do this and it makes sense to me. The key issue is that it must not appear twice as this is just clutter. In the case when the type are from another model and there is no package import then we should see the other model loaded at the root level. Lets say I have my root model, with a lot of sub-sub-sub packages everywhere. I don't import the Primitive Types into the root model, I just use the "Load model" option and use direct references to the primitive types. In this case, I have the Primitive Types model available at the root of my ModelExplorer. Now, one user in one specific sub-sub-sub package deep into the model imports the UML Primitive Types, because he has some specific needs for having them into his Namespace. So now, we have a "PackageImport" element. Should we make the UML Primitive Types disappear from the roots of the ModelExplorer? This doesn't make sense to me. IMHO, it may only make sense if the PackageImport is at the root of the Model (Where it can be found easily, without any need to go deep inside the hundreds of nested packages). Or, from the Properties View dialogs, it may also make sense if the PackageImport is located in the current Namespace (i.e. current package or parents). But then, we'd have different behaviors and displays, depending on where the PackageImport is located, and what we are manipulating. This is not necessarily a bad thing, though. > - #2/#3 I agree a diagram could be provided with a library but that does not mean a user should be allowed, or would want to, create one themselves. I don't see the use-case for the latter. The key aspect of libraries is type re-use. Agreed. I will see what can/should be done and we'll discuss again when this is available for testing. It's difficult to be accurate when the work is still in progress > Comment on #2: > This is (in principle) same problem as in Bug 405586 = should not be allowed. > If a user need to create a diagram for an imported library it must be created > somewhere else, not in the imported library. There are three different and independent things: - Where the diagram is physically located (In which "Resource", i.e. File) - Where the diagram is logically contained (Under which UML Element it is displayed in the ModelExplorer) - What the diagram context is (In which UML Element the elements will be created, if we create new elements in the diagram) Currently, when we create a diagram on a read-only element, the diagram is physically contained in the importing model's notation Resource, logically contained in the imported element, and its context is the read-only element. Because it is physically contained in the importing model's resource, the diagram itself is not read-only: you can move elements around without modifying the imported model, and change all graphical appearances (font, color, size, ...). But I agree this is confusing, and we'll need to (at least) warn the user, or even forbid this action. > Comment on #3: > [...] > This is quite complicated and confusing for users. > If a model has been imported its diagrams should be visible in Model Explorer > right away, which is what users expect when working at the model level. This will be solved along with the refactoring work on the 3-files and PageManager. Many bugs are opened on this topic, and I don't know which one I'll use as the top-task yet. I'll post the link as soon as I have one. > Related to this are the reported lazy-loading bugs. A diagram should not be > loaded into memory until it is actually opened, and only the opened diagram. There is some confusion here, so, to clarify a little bit: 1) Diagrams are always loaded in memory. This is required to display them in the ModelExplorer. It doesn't take more than ~10ms and a few KB of memory per diagram. 2) Diagrams are never displayed until they are opened. Displaying a diagram takes ~ 3 seconds (for each). 3) A Diagram is considered "opened" when the Tab is available in the multi-diagram editor. Opened diagrams are visualized with a blue arrow overlay icon in the ModelExplorer. They can be closed by closing the associated tab. Only 3) needs to be improved, so that diagrams are considered "opened" only when the Tab is activated. See Bug 394779 (Let's keep the issues separated) (In reply to Camille Letavernier from comment #16) > Lets say I have my root model, with a lot of sub-sub-sub packages everywhere. > > I don't import the Primitive Types into the root model, I just use the "Load > model" option and use direct references to the primitive types. In this > case, I have the Primitive Types model available at the root of my > ModelExplorer. > > Now, one user in one specific sub-sub-sub package deep into the model > imports the UML Primitive Types, because he has some specific needs for > having them into his Namespace. So now, we have a "PackageImport" element. > Should we make the UML Primitive Types disappear from the roots of the > ModelExplorer? > > This doesn't make sense to me. [Ronan] What goes on in the sub-packages should have no impact on the root of the Model Explorer. What I would expect is that if I use a type from a Library (marked with the Stereotype <<modelLibrary>> then it does not need to show up in the root of the Model Explorer. I know I can access it from everywhere as it has a global scope. Showing it in the Model Explorer just wastes space. However, if I use a type from another model, that is not a library, I then want to be able to see these models open side by side in the Model Explorer. > There is some confusion here, so, to clarify a little bit: > > 1) Diagrams are always loaded in memory. This is required to display them in > the ModelExplorer. It doesn't take more than ~10ms and a few KB of memory > per diagram. > 2) Diagrams are never displayed until they are opened. Displaying a diagram > takes ~ 3 seconds (for each). > 3) A Diagram is considered "opened" when the Tab is available in the > multi-diagram editor. Opened diagrams are visualized with a blue arrow > overlay icon in the ModelExplorer. They can be closed by closing the > associated tab. > > Only 3) needs to be improved, so that diagrams are considered "opened" only > when the Tab is activated. > > See Bug 394779 (Let's keep the issues separated) [Ronan] Ok :) I think we can close this one. It is odd that I can add a diagram to a read-only library but it is fine now that stores the changes locally. On the issue of the repeated Imports I think I can live with the solution implemented :) The ModelExplorer now displays all imported models; the issue can be closed |