June 28, 2017 1:38 PM, "Martin Desruisseaux" <[email protected]> wrote:
>> About information also uses TreeTable view. I have purposely retained >> the "Type" column to see what data types remain without a customized cell. > > I presume that this is only during development and that this column > would be removed in the final version? Yes in the final version this column will be removed. Until then what you can do is click on the (+) menu button at the top right of the table. There you'll get a check list of what columns to display and you can uncheck the type column. This feature will be available in the next commit that I push. > Minor remarks: when right-clicking twice on a file, it opens two > metadata tabs. Shouldn't the second click bring the focus on the > existing tab? Yes right now there is no check performed to see if a file already has an open metadata tab. When implemented it would be a HashMap of files and their open tab. When a tab is already open, focus will move to it. > What do you think about moving the "About" tab in an "About" menu, which > would show the information in a popup window (as we often see in "About" > box of many software)? The tab structure right now is temporary, for development convenience. All the contents inside the tabs are independent panes with their own fxml files and controllers. These can be shifted anywhere or embedded anywhere (like in an about window) very easily by just modifyng top level fxml and its controller code. I'm following a bottom-up development model. So I'm focusing on the core low-level views such as MetadataView and CRS. Then I'll move up and begin integrating them in the larger app. Thats when features such as shifting to already open tab and cosmetic changes will be done. > Can you have the "Versions" and "Localization" > nodes open by default? (the other ones can stay closed by default). Right now I will write switch-case kind of code which will check the "name" field and accordingly expand or collapse the tab. But a more generic approach is to have preferences file that lists what nodes must be expanded. This can be reused for both About information as well as metadata. Another advantage being that the user can manually edit the file to indicate his preferences. > Did you have some though about designing an overview with > only the main metadata on a flat page? It could be a button in the > metadata tab for allowing users to switch between overview and detailed > view. The generic approach mentioned above can be used for this purpose too. BTW can you elaborate on what constitutes the main metadata? Looking over sample files it seems the "Spatial Representation info" and "Identification info" contain the most useful data so is it the main metadata? > What is the current state of development for other > types? The CRS related types are still remaining. Support is read only. Current UI relies on TreeTable's decomposition of types into more primitive types which can be suboptimal. For example GeographicBoundingBox defines 2 latitudes and 2 longitudes which appear as children under "Extent" node. Problems with current approach: * occupy 4 rows of the table vertically * Exposed as a double, without information about its range, so out of range values can be put in and lead to exceptions. * All 4 doubles are independent. But in reality the south bound latitude cannot be greater than the north bound. Exception thrown again. A more optimal and intuitive UI control would be one horizontal range slider for longitude (-180 to +180) and a vertical range slider for latitude (-90 to +90). The range slider will automatically ensure that the south value doesn't exceed north. It can also enforce precision of 0.01° as per documentation. NOTE: range slider is a part of controlsfx and I just figured out it will be very useful in this project. > If all the main types are completed, what is your plan for the > next step? When all types are covered I'll move on to the 'workflow' of the application. Regards Siddhesh Rane
