[suggestion] You need to segragate read-only vs. writeable directories, and make the installed structure unix-like

[yurivict]

Currently you install everything under $(PREFIX)/viewtouch/. This isn't how software is installed on unix-like systems. About every package there is installs binaries into $(PREFIX)/bin, data into $(PREFIX)/share/{name}. These two are read-only. The writable data can't go under $(PREFIX), it normally goes either into /var/db/{name}/, or is written into the home directory, or is written into some specifically designated, separate directory.

The above discrepancy is why no linux distros created a package for ViewTouch - it doesn't fit the way how they do things.

Here's what you can do to adjust:

1. Expose the variable VIEWTOUCH_INSTALL_PATH as a cmake option, have "/usr/viewtouch" as a default. Install all read-only files under it, with data going into ${VIEWTOUCH_INSTALL_PATH}/share/ViewTouch, and executables - into ${VIEWTOUCH_INSTALL_PATH}/bin,
2. Expose the variable VIEWTOUCH_DB_PATH for writable files. Keep the default of "/usr/viewtouch/dat", but this would allow people to set it to "/var/db/ViewTouch", for example.
3. It writes into bin/.vtpos_command, this also should go under the writeable directory VIEWTOUCH_DB_PATH, etc.
4. Ideally, you could also have a variable USE_HOME_DIR_FOR_DB, in which case it would just write the DB into a home directory.

If you make alterations that I am suggesting in the above instructions, it would be possible to install it into a single directory, like before, and in a way how unix-like systems install software.

I've ported ViewTouch, but encountered these discrepancies that prevent me from creating a port at this point.

[GeneMosher]

I must point out that I'm not a programmer and have no training in how to design software. The design error you are pointing out (and perhaps can fix) can be explained by the fact that none of the software engineers whom I ever employed and were involved in writing ViewTouch code seem to have been aware of what you are bringing to our attention. Software, as you know, is never done, and there are always improvements, extensions or fixes of breakage which cry out for attention. Nothing would make me happier (well, almost nothing) than to have you contribute this improvement/fix for everyone's benefit, so I can only thank you in advance if you would offer a bit of your time and your knowledge of this situation to remedy it. One other thing I would ask, is that you keep in mind I am kind of the manager here since day one and I really need to understand in plain English what changes are being made so I can ensure the wiki and other documentation provides a completely adequate explanation of what and why something is being done here. I trust this all sits fine with you, Yuri, and please let me know anything I myself should do here that I am able to do.

[GeneMosher]

Yurivict; you made an excellent suggestion to us in May, 2019 which I am at long last preparing to implement, with the help of a couple of others - segregating read-only vs. writeable directories. If you would like to offer any more details as to what we need to do to make this happen then I would certainly appreciate this. I do think this and your other suggestion, also from May 2019, are both excellent and it is my regret that I didn't sooner integrate them both as enhancements until now.

Note: the Filesystem Heirarchy Standard is at https://www.pathname.com/fhs/pub/fhs-2.3.html

FreeBSD Heirarchy: https://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7&manpath=freebsd-release-ports

A discussion: https://unix.stackexchange.com/questions/139764/what-are-the-world-writable-directories-by-default

[GeneMosher]

Anyone is free to make these suggested changes but no one has exercised their right to make these changes so the assumption going forward with regard to this issue is that it is not important enough to anyone that any action on this suggestion needs to be taken, hence I will close this issue. If anyone chooses to take action on this suggestion in the future they are certainly entitled to do so.