Based on @Dhruv_J comments here about not seeing debugging messages on Windows … I looked into it a bit more.
It seems like we can redirect all debugging / warning messages from Avogadro qDebug() into a file:
So what should we name this file, and where should we put it for Windows users?
In other words, let’s say AvogadroMessages.txt is the name of the file. Do we leave it in the HOME directory? Or Documents? An avogadro directory in Documents?
If I get some input on the location, I’ll whip up a new Windows build today.
I found that access to temp folders after the program has terminated can’t be guaranteed on all OSes. I suggest either
QStandardPaths::AppLocalDataLocation
which on Windows then ends up being the C:/Users/<USER>/AppData/Local/<APPNAME> i.e. exactly (EDIT: roughly, see below) as @Ineluki suggested if it goes in a logs subfolder. This points to ~/.local/share/<APPNAME> on Linux.
Or, alternatively:
QStandardPaths::CacheLocation
which on Windows is just C:/Users/<USER>/AppData/Local/<APPNAME>/cache but on macOS and Linux goes to ~/Library/Caches/<APPNAME> and ~/.cache/<APPNAME> respectively.
But I’d be for the first option, as it is where Avogadro already puts e.g. plugins. For what it’s worth, Steam puts its logs under ~/.local/share/Steam/logs on my machine, and several games do similar. Krita just sticks them directly in ~/.local/share.
You are absolutely correct, of course, the environment variable (generally) does point to the roaming folder.
However, it seems that when using QStandardPaths (which allows things to be nicely cross-platform) you have to choose between QStandardPaths::AppDataLocation, which points to the roaming profile on Windows, and QStandardPaths::AppLocalDataLocation, which points to the local profile.
It makes little sense for plugins and log files to follow users from machine to machine in an Active Directory environment, as Avogadro might only be installed locally on one PC. So using QStandardPaths::AppLocalDataLocation and AppData/Local seems the better option to me.
Really? I disagree, which is why I went with AppDataLocation - consider a managed lab in a university.
I’m happy to put the log wherever - it’s about 1-2 lines of code. The main thing, in this case, is for someone to use the log (currently at Documents / avogadro2.log) to help figure out why plugins don’t work for Windows users.
I do consider that – I’m IT admin in my group so that is our main use case. I don’t think it matters all that much, it’s just that I have had bad experiences with things synchronising properly. And if roaming profiles get too large it takes absolutely forever to log in and out. But if you disagree it’s not an issue for me!
That’s fine of course, but note that actually, according to the docs, and your post about the actual bug in question, it is stated that AppLocalDataLocation is being used.
Absolutely. If nothing gets worked out by tomorrow I can go into uni and have a look on a PC there, if you want.
Thanks for the fast reply. I did not know that a log file is written in Documents. Did I miss it in the documentation ? Unfortunately I can only check the log’s content tomorrow. Maybe then I can figure out what’s going wrong or where to look for / put the plugins .
It’s in the latest nightly build - I didn’t realize Windows doesn’t show console / command-line messages.
The log will definitely help … and can be stashed wherever.
If you have a chance to test, I’d also be curious about the new optimize geometry. It’s been tested on Mac and Linux, but I haven’t had time to check on Windows yet.
I don’t think it matters all that much, it’s just that I have had bad experiences with things synchronising properly. And if roaming profiles get too large it takes absolutely forever to log in and out. But if you disagree it’s not an issue for me!