Thanks for your work! I added a few comments as bold/italic preceded with a "kiozen:". Remove them after you have read them.
Sadly Bitbucket does not provide the same pull request/review process for changes on the wiki. Therefor writing it and discussing it the way we do now is the way to go. I wait since 2008 for a native speaker to correct my crude English. So forget about that part. I explained the mounting behavior in one of my comments. Oliver Am 21.06.2016 um 00:00 schrieb Wolfgang Rosner: > Hello, > > I just finished a draft of page "How to save your work" > > https://bitbucket.org/maproom/qmapshack/wiki/edit/How%20to%20Save%20Your%20Work > > You may link it from your main documentaion, if you consider it > valuable for the public. > > During writing, some more questions arose: > > - can you, please, have a look at it, if it contains any nonsense from > your experienced point of view? > > - when / how is the ~/current.view file written? Or is it just > produced at installation time as a first start? > > - Can I produce a clone of gpx files as qms and vice versa by the "save > as" dialogue , respecting the limited capabilites of gpx containing > object history, of course? > > - I feel the mounting behaviour for device access a little bit weird. > Usually, I'd expect the device being automounted upon access by any > application (as QMapShack) or getting some error, if it is not yet > mounted and not properly configured for automounting. On the other > hand, It should not be possible to properly unmount the device, while > still any app accesses it. However, the behaviour of QMapShack in > this issue resembles the old DOS-World: hope the best and don't care > for anything. Looks like it bypasses basic mounting functionality? > What have I missed? > > - is there any proof read procedure established in your project? I'd > like to have native english speaker gleaned over the text, and maybe > respone from some average users. > > Wolfgang Rosner > > > Am Mon, 20 Jun 2016 18:29:26 +0200 > schrieb Oliver Eichler <[email protected]>: > >> >> 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 > > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Qlandkartegt-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
