Prep Meeting Jan 31
News
Jean Philippe Daigle?: had a bad night, going to be very late, don't wait up. May or may not be there before the end of the meeting; will definately be there to work on embedded s/w lab report afterward.
Q: Do all UCM diagrams have a name? Is this name unique within a project?
-
- Yes
- No
- Maybe
- CowboyNeal names my diagrams
- They're orphans you insensitive clod!
Difficulties EMF+GEF
-
- Etienne and Jordan will talk about the difficulties encountered while doing a simple network editor.
- Difference between an EMF model and a normal model advantages/disavantages.
- Agregation vs Composition in EMF
- Discussion about Commands to change an EMF model in GEF.
CVS + Eclipse Team Synchronizing
-
- I think we could really use this right now since some of use are starting to code a lot.
- What do we have to do to make it working?
- New repository up. /projetseg instead of /cvs. (--JK)
- From now on, one project = one module. (--JK)
Model persistence
- I strongly suggest we save our EMF model in XMI format instead of formatting with our own DTD.
- Eclipse REQUIRES files/folders be in a project.
- Hence, projects are mandatory constructs for our tool.
- Projects contain metadata and folders/files.
- After researching, I believe, as opposed to what Daniel Amyot suggested before, that diagrams should all have their seperate .jucm files. This concerns UIMockup Details Views as well.
- EMF will manage file references for us.
- Memory consumed by one single file will be reduced.
- UI metaphors will be respected easier
- Only one editor can be open for any particular editor input in a workbench page. For example, if the user is editing readme.txt in the workbench, opening it again in the same perspective will activate the same editor. (You can open another editor on the same file from a different workbench window or perspective). Unlike views, however, the same editor type, such as a text editor, may be open many times within one workbench page for different inputs.
- Two generic editor inputs are provided in the platform. IFile Editor Input? represents an input that is a file in the file system. IStorage Editor Input? represents an input that is a stream of bytes. These bytes may come from sources other than the file system.
- Interface IFile Editor Input?: File-oriented editors should support this as a valid input type, and allow full read-write editing of its content.
- Interface IStorage Editor Input?: File-oriented editors should support this as a valid input type, and display its content for viewing (but not allow modification). Within the editor, the "save" and "save as" operations should create a new file resource within the workspace.
- Here's why I don't see the different diagrams opened in different bottom tabs:
- I posted the following on the eclipse newsgroup
We're developing a plug-in for Eclipse to modify a particular visual notation. The notation consists of diagrams which contain, among others, stubs. Stubs are placeholders for one or more other diagrams. To make a long story short, we want our editor to display a diagram and when someone double clicks on a stub, the other diagram is shown.
The current version of the notation has all diagrams self contained in one XML file. Along with our plug-in, we'll be introducing a new version of the notation. We're discussing two options:
1) One XML file contains all diagrams.
2) One XML file per diagram. We want to be able to have multiple diagrams opened simultaneously. My question is the following: If we have only one file to contain all diagrams, is it possible to load different editors that use(read/modify/write) different portions of the same resource? My reading shows me:
Only one editor can be open for any particular editor input in a workbench page. For example, if the user is editing readme.txt in the workbench, opening it again in the same perspective will activate the same editor. (You can open another editor on the same file from a different workbench window or perspective). Unlike views, however, the same editor type, such as a text editor, may be open many times within one workbench page for different inputs. Is it just me or even if we managed to seperate our files into different chunks where each chunk could be opened seperately, we'd probably run into a truck load of problems relating to file modification notations when we would try to save. Do you have any examples of plugins for visual notations using recursive editors? I'm really interested in seeing how to respect the Eclipse UI guidelines by using the right metaphors. Are these using different editors for each portion, the same one with some other navigation mechanism, etc. Thanks for your time,
Jason Kealey
jkealey@shade.ca
One editor per resource per window. You could open different diagrams in different tabs (Multi Editor?) but since there are probably a variable number of diagrams, this won't work. If you go down the one XML file per diagram path, you will find there's no mechanism to ensure that multiple files are kept in sync (which I imagine is what you're worried about). You could work around that by finding all the open editors on "your" files and forcing a save in each one. Not sure how that will look in the UI. And, of course, one of the saves could fail. To switch between editors, you can simply use the API to open your editor on the resource. IIRC, if it is already open, it will come to the foreground. If not, it will be opened. To cause the other editor to reposition within a diagram, though, would involve some inter-editor communication. Bob Foster
2) One XML file per diagram. We want to be able to have multiple diagrams opened simultaneously. My question is the following: If we have only one file to contain all diagrams, is it possible to load different editors that use(read/modify/write) different portions of the same resource? My reading shows me:
Only one editor can be open for any particular editor input in a workbench page. For example, if the user is editing readme.txt in the workbench, opening it again in the same perspective will activate the same editor. (You can open another editor on the same file from a different workbench window or perspective). Unlike views, however, the same editor type, such as a text editor, may be open many times within one workbench page for different inputs. Is it just me or even if we managed to seperate our files into different chunks where each chunk could be opened seperately, we'd probably run into a truck load of problems relating to file modification notations when we would try to save. Do you have any examples of plugins for visual notations using recursive editors? I'm really interested in seeing how to respect the Eclipse UI guidelines by using the right metaphors. Are these using different editors for each portion, the same one with some other navigation mechanism, etc. Thanks for your time,
Jason Kealey
jkealey@shade.ca
One editor per resource per window. You could open different diagrams in different tabs (Multi Editor?) but since there are probably a variable number of diagrams, this won't work. If you go down the one XML file per diagram path, you will find there's no mechanism to ensure that multiple files are kept in sync (which I imagine is what you're worried about). You could work around that by finding all the open editors on "your" files and forcing a save in each one. Not sure how that will look in the UI. And, of course, one of the saves could fail. To switch between editors, you can simply use the API to open your editor on the resource. IIRC, if it is already open, it will come to the foreground. If not, it will be opened. To cause the other editor to reposition within a diagram, though, would involve some inter-editor communication. Bob Foster
-
- Issues I foresee (you will probably see more):
- You delete a diagram or change an interface.
- The parent must be changed to remove/correct references to this diagram.
- You quit eclipse, don't save the parent diagram. Invalid UCM diagram ===> Not allowed.
- Will have to implement some sort of batch save when things like this happen.
- User restores some files in the project from a backup; creates invalid project.
- Issues I foresee (you will probably see more):
UCMNav Requirements
- I think what is missing is an exact definition of all the 'items' that are to be supported. What properties they have, how can they behave, to what other 'items' can they be connected to? Should study the DTD or will this come?
- -- Daniel Amyot - 31 Jan 2005: Many things are still missing, in no particular order... (-- Jason Kealey : Striking out what has been created)
- Mandatory elements:
start, end, respomsibility, static/dynamic stubs, wait/timer, AND fork/join, OR fork/join,logical guard conditions,"empty" point,direction arrow - Mandatory connections ("connect" element):
end to start/wait/timer, empty point to start/wait/timer - Optional elements (future?):
dynamic responsibilities, dynamic components, pools, shared responsibilities and stubs, goals, aborts, timestamps, loops, failure point - Performance annotations
- Stubs:
create plug-in, view plug-in, add plug-in, duplicate plug-in, import plug-in, remove plug-in, rename plug-in, bind plug-in, properties - Labels:
moveable (X-Y delta from anchor) - Delete: issues with delete a branch, a stub, a group of elements
- Components: user-defined types, default shapes, resize
(couple/decouple), move, colour (line and fill), send to back, cut/copy/paste - Work area: zoom (+/-, fit, number), scrolling, keyboard shortcuts
-
Group of elements: move, delete, - Visual comments
- Attributes: will come with the metamodel
- ...
- Mandatory elements:
Comments about current UCMNav Requirements
- Undo/redo framework: Built into EMF, right? (Indirectly, see chapter 5.2.3 of redbook)
- Req Char Bound Start End: What if you have multiple parents?
- Req File Association: .jacm or .jucm? I'm not sure we can event link to eclipse as a default editor because all files must be in projects. We'll have to investigate. For file paths, in the Resource API, they use a common scheme that is mapped to the file system. At the file system level, we might have to deal differently with these but probably the Java VM will help.
- Req Goal Browsing: since when did this go from a potential metaphor to a mandatory one?
- Req Goal Command Line: Therefore, we must try to seperate EMF and GEF as much as possible. We may have to add another layer in which our commands are self contained and not held strongly linked to GEF. Etienne Tremblay might have a better idea on how all of this should be architectured.
- Req Goal Grl Support: Then why is it called j UCM Nav?
- Because jGRLNav doesn't sound very good. -- Jean Philippe Daigle? - 31 Jan 2005
- Req Save Auto: If I am not mistaken, this seems to go against the Eclipse UI guidelines and it is mandatory?
- (JP: EG6.2)Modifications made in an editor follow an open-save-close lifecycle model. When an editor first opens, the editor contents should be unmodified (clean). If the contents are modified, the editor should communicate this change to the platform. In response, an asterisk will appear in the editor tab. The modifications should be buffered within the edit model, until such a time as the user explicitly saves them. At that point, the modifications should be committed to the model storage.
| I | Attachment | Action | Size | Date | Who | Comment |
|---|---|---|---|---|---|---|
 png |
allowedConnections.png | manage | 28.9 K | 31 Jan 2005 - 00:13 | Daniel Amyot | Extract from Z.152 |
Topic revision: r11 - 18 Feb 2005 - 09:43:46 - Jason Kealey
 |
|
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback