| [EMFForms] Support for Nebula's GeoMap widget [message #1754499] |
Sat, 18 February 2017 22:10  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm the developer of Nebula's GeoMap widget (https://eclipse.org/nebula/widgets/geomap/geomap.php), and I'm considering adding support for it to EMF Forms (as an extension in its own bundle, of course). GeoMap is both an SWT-based widget for showing a tile-based map and supports JFace, where it is a viewer and editor for geo-locations on top of the map. There are interfaces for providing support for viewing and editing geo-locations in pojos, and I've already made a view that attaches to any IEditingDomainProvider and shows the geo-locations in EObjects within an Resource or EObject hierarchy. Hence, I don't expect it to be a huge effort.
But is it worth it? Do you think it is a good idea?
Regards,
Hallvard
---
Hallvard Trætteberg (hal@idi.ntnu.no)
Associate Professor, IS group, Dept. of Computer and Information Science at the
Norwegian Univ. of Science and Technology
|
|
|
|
|
|
| Re: [EMFForms] Support for Nebula's GeoMap widget [message #1754791 is a reply to message #1754788] |
Wed, 22 February 2017 12:57  |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
|
The GeoMapViewer has a content provider that returns all the elements for which it should show a location. This is similar to the content provider of a table (or tree, but a tree content provider also returns children/parents). Then a location provider returns a geo-location for each of the elements returned by the content provider. In addition, a label provider gives the text shown by the location marker. A view model could allow me to add a GeoMap element with attributes/references that allowed me to create the content provider, location provider and label provider. The existing view model contains elements that are similar, in the sense that they are used for providing (sub)elements and labels, so these could be reused. E.g. FeaturePathDomainModelReference could be used for all these, one for the elements, one or two for the location and one for the label (although you could have more, and a format string, for greater flexibility). Extending the view model (view.ecore) is natural in this case, since there are more things to configure than for simpler controls. I've found table.ecore in org.eclipse.emf.ecp.view.table.model, should I use this as the starting point/inspiration?
|
|
|
|
Powered by
FUDForum. Page generated in 0.01551 seconds
] 
Search
Help
Register
Login
Home
