Hello Siddhesh Thanks for the update, this is encouraging!
Le 20/06/2017 à 16:40, [email protected] a écrit : > The tree table uses org.apache.sis.util.collection.TreeTable as the > model instead of Metadata directly. I assume this class is very > general purpose and flexible for many kinds of data. > Yes, I think this is the right approach. There is some proposals for the metadata tab: * Omit the "Text" part, show only the "Tree table" part. * Omit the "Identifier", "Index" and "Type" columns; show only the "Name" and "Value" columns. We may need the "Identifier", "Index" and "Type" columns internally, but we don't need to show them to the user. * In the "Value" column, we will need specialized Java code for some types. I suggest to begin with org.opengis.util.ControlledVocabulary (the common interface for Enum and CodeList): when a value is an instance of that type, invoke name() instead than toString() for obtaining the text to show. If the tree table were editable, it would be a combo box. > The diagnostics information on home page obtained using > About.configuration() also returns a TreeTable object. I can display > that also as a tree table if you want, although the screen was mainly > for development purposes as I added or removed runtime dependencies. > Yes, I think they would be very helpful information as a tree table, using the same renderer than for metadata objects. I suggest to put that in an "About Apache SIS" menu (I don't think it needs to be a tab). > In the latest commit the CRS tab is a table that lists all installed > CRS Codes. There is also a search box to filter codes. > The search box currently filters on EPSG codes. I think we will need more search criterion: * By description * By type (Projected, Geographic, Vertical, Temporal, Engineering) * By area of validity (if possible by drawing a rectangle on a map) * Alternatively, by area of validity specified by country name * More criterion may be added later. For example we may consider adding the scope of use (small scape mapping, geodetic survey, oil industry operation, coastal hydrography, military mapping, highway engineering, etc.). Given that the search criterion can be sophisticated, we may need more space than a search box. Maybe a panel on the left side or right side of the table? In the table, we may need a third column giving the CRS type where the values (for now) can be "Projected", "Geographic", "Vertical", "Temporal" or "Engineering". It could be icons if we have some nice pictures that fit in the available space, but let skip that if too hard. > For this component I have taken cues from an equivalent geotoolkit > component, and done a verbatim copy of > org.geotoolkit.gui.javafx.crs.Code with a minor addition of a getter > method. The original code is LGPL licensed, so inform me what license > work needs to be done. > It is okay, I just did the IP review on that class (nothing more to do on your side): http://svn.apache.org/repos/asf/sis/ip-review/Code%20(Swing%20CRS%20chooser).xhtml > By agile/scrum I actually intended some form of issue and project task > tracking. JIRA's scrum turns out be too much for this project. Instead > I have set-up Github Projects at > https://github.com/SiddheshRane/sis-client/projects. What I've done > here is list To Do, In Progress and Done tasks. The tasks will be very > low level, elementary units of functionality however minute and their > description will refer code sections and APIs that they require. This > way you will get a precise idea about how the implementation is going on. > Thanks, let use that then. One additional comment: when executing the application, I initially got a ClassNotFoundError. I got it working by adding the following dependency in the pom.xml: <dependency> <groupId>org.controlsfx</groupId> <artifactId>controlsfx</artifactId> <version>8.40.12</version> </dependency> I would also like which widgets from those external libraries are used? Would it be possible to build the application using only the JavaFX provided in JDK 8 or 9? Martin
