A few general issues and gripes

[drws]

I'm exploring the Linux version of this interesting piece of software and I quickly noticed some general issues and gripes, mostly related to basic software configuration (non-audio-related). First of all REW always creates the /home/user/REW directory if it's missing and I couldn't find any options in the Preferences to change this path. Forcing the user to use a hardcoded path is not really nice. I believe that user should be asked about the working directory at first start of the application, like with the update settings, and any directory should be created or written to only after the user selects it.

The other thing with the working directory is that REW constantly writes logfiles to it which might be undesired by some users and again I couldn't find any preference to turn that off.

I mentioned the update settings that can be set at the first startup, but again, I couldn't find any option to change update-related settings afterwards.

It seems like the program needs a "General" tab in the Preferences or similar where these general settings (paths, logging, update and such) were available to access at any time. Alternatively, a readable configuration file could be used. Where does REW in fact store its configuration values on Linux? I checked the docs, but couldn't find it. Is it documented somewhere?

 

[John Mulcahy]

The REW directory is for REW's use, paths for user files are remembered when the user chooses them.

Update checking options are in the help menu:

Per the help, on Linux preferences are typically stored in ~/.java/.userPrefs/room eq wizard/prefs.xml

In more detail, courtesy of Oracle: On Linux systems, the system preferences are typically stored at java-home/.systemPrefs in a network installation, or /etc/.java/.systemPrefs in a local installation. If both are present, /etc/.java/.systemPrefs takes precedence. The system preferences location can be overridden by setting the system property java.util.prefs.systemRoot. The user preferences are typically stored at user-home/.java/.userPrefs.

 

[drws]

I could've sworn I checked the Help menu for update settings as well, but obviously not good enough. Thank you for clearing that up and the configuration path as well, it all adds up.

Setting the logging issue aside (if REW needs these files to operate, user is still left with the option to mount the relevant directory as tmpfs), the hardcoded path is really not doing such great program a favour. I kindly ask you to rethink this issue and possibly implement some way to set this path.

Even if you don't want to make the path configurable, the standard solution would be to make the folder hidden by renaming it to ~/.REW or ~/.roomeqwizard to not as obviously litter the user's home folder. Alternatively, the REW folder could also be moved to more or less standard ~/.cache/REW or ~/.local/share/REW.

 

[drws]

Sorry to bug you, but I'd like to hear your take on my previous answer.

I've noticed another possible bug. The umask for my system is set so that newly created files and directories can get permissions rwxr-x---. Nonetheless the ~/REW folder and its files get permissions rwxr-xr-x. It could be a JRE issue, but if REW hardcodes these, I'd suggest that the umask standard is taken into account.

 

[John Mulcahy]

Installation is handled by install4j with default Unix file mode 644, default directory mode 755. REW doesn't set any explicit permissions for files it creates beyond requesting that they are read/write, details of any resulting file permissions are below REW's abstraction level.

The log files folder has content that is helpful for fault finding and debugging. Making it hard for users to find by hiding it would, in my experience, be a retrograde step. I'll add a todo list item to make the location configurable, but the todo list is long and there is no timetable for when things on it get done.

 

[drws]

Thank you for clearing up permission-setting as well and especially for reconsidering the REW folder issue. I understand you have other things to do and that it might take time. I guess this concludes the topic.

 

[drws]

I asked install4j devs about the umask issue and it seems that you can achieve system umask conformity by setting the compiler variable sys.ext.installerUmask=false. This might break installation with certain umasks, but then again it is better not to guess/invent permissions and to conform to a standard system-wide setting. If the umask is set up too rigorously that's up to the user (and possibly intentional).

 

[John Mulcahy]

I have set sys.ext.installerUmask to false for the next build.