VCityTeam / 3DUSE

Other
5 stars 5 forks source link

Provide a way to add new DataProfiles #37

Open EricBoix opened 7 years ago

EricBoix commented 7 years ago

Issue by jeremyedert Tuesday Apr 26, 2016 at 08:41 GMT Originally opened as https://github.com/MEPP-team/VCity/issues/103


3DUSE uses a class called DataProfile that contains all the settings regarding the position of data. Notably:

Currently, 3DUSE provides 3 preset DataProfile: Paris, Lyon, and "None". FloodAR adds a DataProfile for Sablons. The values for these data profiles are set in C++ code in dataprofile.cpp. The data profile can be changed during runtime in the settings dialog by selecting a data profile other than the one currently in use (no matter which one), and editing manually the values. This change is only effective until the data profile is changed again or the application is closed. There is no way to save a new data profile.

A user that works on a new area and wants a new DataProfile (for instance, to have the grid on the main window) need to edit the settings window at each runtime, or ask the developpers to add a new DataProfile to the application.

It may be judicious to provide a way to save/read a DataProfile in a configuration file or equivalent to avoid this issue. Also, as the dataprofile is strongly related to the "current" dataset, maybe such files can be stored and opened along data?

EricBoix commented 7 years ago

Comment by fpedrinis Tuesday Jul 12, 2016 at 13:18 GMT


Where can we put such files ? They have to be accessible from 3D-Use project in each OS, but also from the Windows package installed on computer without the resources stored in Github.

This is probably the same problem as in issue #79.

Alternative : propose to the user to choose the folder when datasets will be stored. This path will be saved in QSettings as in the plugin Visibility.

EricBoix commented 7 years ago

Comment by frogsapo Wednesday Sep 07, 2016 at 12:22 GMT


Part of the job (accessing a file in a portable manner) was done with the skybox. We should create a new issue requiring to have at hand (in a portable manner) a directory at installation stage (as opposed to build stage). Then the present issue should be made dependent of this new issue...