Local help does not currently work (ticket #2316) and building it
is a bit painful in Windows. Hence it was decided on ticket #2677
and at IRC that we open on-line help from GUI until the local
help issue is solved.
Add applying of filtering into list of files to check if we have
an active project file. Filtering is quite much similar to the
filtering in CLI.
If we have directory filter ("gui/") then we check all paths if
they contain "gui" part. In practice we search for string "/gui"
from the paths. If we have filename filtering
("gui/projectfile.cpp") then we check if any of the paths end
with that.
If there were unknown language in settings the fallback to English
language didn't work as expected. And there were no proper current
language set after that. Initialize current language to English
so we always have English as proper fallback.
GUI was storing selected language as index to the languages list.
This is fragile since the order and count of items can change.
This commit changes to using ISO language code (e.g. "en" for
"English").
Fixes ticket #2446 (GUI: Don't use index number for language selection)
Settings-dialog is more natural place for language selection than
the main menu. We also have more space and freedom there to have
longer text etc to make the selection easier (menus are quite limited
controls).
Dan added new enable-flag for information messages in commit 033e759.
Enable that flag for GUI so that the information messages are visible
in the GUI.
This commit adds new setting and GUI for global include dirs. When
project file with include dirs is loaded, global includes dirs are
added first and after them the include dirs from project file.
Debug errors were not shown anywhere in the GUI, they were just
ignored. This commit adds new signal for those debug errors and
directs them to checking log.
Solves ticket #1898 (GUI: Handle internal errors from lib)
* moved the help file to the application folder
* use absolute path instead of relative path for helpfile
* show warning messages if help file doesn't exist or fails to be loaded
Project closing action was not enabled when the project file was
opened from the checked directory. Also update the window caption to
contain project file name that was opened from the checked
directory.
The GUI was crashing if no project files were in checked directory.
I missed this case in my own testing because I had created test
project files for each directory. Whoops!
Anyway, this now also makes silently loaded project files (project
file residing in directory but not load by the user) as normal
projects in the GUI.
If rootpath is given in project file then use it as a current
directory. Also check if paths given in project file are
relative and use rootpath as base path for relative paths.