Am 20.06.2016 um 16:03 schrieb Wolfgang Rosner: > Am Mon, 20 Jun 2016 13:21:15 +0200 > schrieb Oliver Eichler <[email protected]>: > > Hello, Oliver Eichler > >> That said you will find the autosave feature in Project->Setup >> Workspace. > > So I was just asking for another feature that was implemented long ago > but did net yet find its way into documentation, right?
Yes, most likely. > > This confirms my assumption that some improvement in documentation > might be helpful. Yes, this is always true :) > Do I understand this correct: > When I have an unexpected crash of QMS, (or close it without saving > changes into all of the projects), > on reopening QMS, > - all my changes will be restored into application memory to the state > of last automatic save. Yes. > - All projects (inlcuding all gmx files) will be unchanged, but > reopened. No. They are not re-opend. Once a gpx/qms file is loaded it belongs to the project entity in the workspace. Of course this entity know the path to the original file. That is why the entity can be saved back to the file. > - All the changes made (at the time of last autosave) will be displayed > as changes still unsaved into their relevant project files (with the > asterisk benath). Yes > > Can I manually trigger this saving of the workspace? e.g after some > chunk of work where I am still not yet sure whether I want to mess up > all my gmx files opened? No. If you are so much afraid to loose work reduce the interval to save the workspace. > > Can I trigger the save of my workspace to a given filename (or copy the > saved state in the backgroud) to implement some kind of versions of my > work I could roll back on demand? No. There is only one workspace database. And the intended use of the workspace database is just to freeze your current state of work over different sessions. > > Or is it preferrably to organize rollback of work with versionized > project files? Well, I see that I have version control within each > object. But I suppose this is not kept in sync between different objcts > or even between different projects - am I correct? And is the rerollable > history saved in *.gpx files, too, or only in *.qms files? No gpx has no sensible mechanism to store a history. That would end up in a mess of extension tags. If not exported as GPX everything is handled in the *qms format. Even QMapShack-internally and in the databases. In the database an item is usually stored only once and referenced by one or several projects. As a consequence it will change for all projects if saved into the database. If you have an item in several projects on the workspace it is not synchronized on-the-fly in the workspace. But QMapShack detects if you want to save different versions and asks what to do. > > Not that I want to request another feature - just want to make sure > before I write bullshit in what' supposed to enter a manual. ;) So far I just read valid questions. It's always ok to ask. > > > I find a directory ~/.QMapShack, but only map related subdirs in it. Right that is the TMS tile cache. Use File->Setup Map Paths to change it > > ah - ... lsof ... is it this? > ls ~/.config/QLandkarte/ > QMapShack.conf WaypointIcons workspace.db workspace.db-journal > > Is it advisable to point users to this dir? > Or is it too risky to screw things up? Well that is the Linux way to store configurations and application dependent data that is not temporary. Usually a user should have to bother. At least not until they screwed up QMapShack.conf :) WaypointIcons doesn't really belong there but I do not know a better place for the default. You can change it in Project -> Setup Waypoint Icons > The name "workspace.db-journal" sounds like belonging to a journalling > database. This begs the question whether there is more on rollback than > individual objects alone? Somekind of transaction log? Is it > transparent to the user? May it be in the future? It's the journalling file of SQLite and of no use once you closed the application. And I do not think it's a wise thing to use the journalling mechanism of a database for a undo/redo feature on the user side. Also keep in mind that GIS projects are a bit more complex than a text document or similar. Each item can be changed independently. Thus the history have to be maintained for each item independently, too > > Is there a difference between the concepts > "Kartenansicht" und "Arbeitsplatz", as the german locale suggests? > "Project \ Arbeitsplatz konfigurieren \ ... speichern ...." > vs "Datei \ Kartenansicht speichern" There is only one Workspace holding all your loaded GIS data. The data can be displayed on one or several Views. A View is defined by a selection of maps and DEM files and is independent from the data in the Workspace. > Can I easily switch temporarily the language displayed? > e.g. by some environment variable and call QMS from the command line? On Linux you can enter in a console: export LAND=C and start QMS from that console. This wil give you the default language (English) export LAND=fr will give you French and so on. > > When I engage in documentation, I think its preferrable to start with > english versions. However, I don't want to switch to default english > applications. Yes, please all screenshots with the default language profile. (export LANG=C) Another important feature is the "-c" commandline option to load a local configuration file. You don't want to nuke your normal configuration each time you write documentation. ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
