some small fixes

[khrykin]

Thank you for the input! There are some things to discuss before we could merge:

• Regarding moving to other platforms, I think it would be better to just place all single-header deps in system's include location or make project-level include folder and place them there, so I've removed find_package for nlohmann::json.
• I've used QSystemTrayIcon just to showMessage in the past, now notifications are presented via native APIs both on macOS and Windows. Actually, now I'm almost ready to commit completely new notifications machinery, built with mobile platforms in mind, so there's probably no need to make changes here.
• I think I changed .otf to .ttf, because I couldn't get .otf to work on Windows, can you please tell why would we prefer .otf here?

[borco]

• there are still includes for nlohmann::json -- this is why I've added it -- but haven't check if you're actually using anything from that lib
• there is no .ttf in github, only the .otf -- this is why I've changed the reference

[khrykin]

• nlohmann::json is used, and it's single-header, so the idea is that cmake doesn't need to know anything about it. Can you please conform your version to CMakeLists.txt on the master branch?
• That's my bad, thank you! It should be .ttf, it was left uncommitted.

[borco]

According to https://github.com/nlohmann/json/blob/develop/README.md, you have to use something like this:

# CMakeLists.txt
find_package(nlohmann_json 3.2.0 REQUIRED)
...
add_library(foo ...)
...
target_link_libraries(foo PRIVATE nlohmann_json::nlohmann_json)

Without it, the code didn't compile on my machine -- how would you preffer the CMakeLists.txt to handle it?

[khrykin]

Right now I have a symlink to nlohmann folder (the one with json.hpp file) in /usr/local/include on my Mac, which makes it automatically accessible for the compiler, without any cmake intervention. If it doesn't compile this way, you could check that /usr/local/include is set as an include location for your compiler, which it should.

Again, I'm thinking of moving all dependencies except boost and Qt right into the project tree to reduce the hassle for the new contributors. In this case we could make folders like third-party/lib and third-party/include, then in CmakeLists.txt we would just include_directories(third-party/include) and set(CMAKE_LIBRARY_PATH third-party/lib).

[borco]

I guess there is no perfect solution to this, but including other projects into yours, especially if you plan to split their sources will become a maintenance problem in the future, if you want to upgrade the dependencies.

In my opinion, adding them as git submodules under third-party works better. Especially because you can then create a custom CMakeLists.txt in third-party that replaces the ones provided by those third-library packages and this way provide a better/customized integration with your app.

This is what I currently do in my Qt apps. For example, in this older app of mine (more or less...): https://github.com/borco/tutcatalog/tree/master/src/3rd-party

[khrykin]

Submodules would be ok for header-only libs, but I was thinking of including pre-built binaries for all supported platforms, so people wouldn't have to compile specific versions of dependencies themselves. If we want to upgrade - recompile new versions, swap binaries and headers, that's it?

[borco]

I am very much against including binary libs that can be built from sources into git and transform git into some kind of CI artifact placeholder. Better configure the repo to use AppVeyor and Travis if you want some precompiled stuff. That’s my opinion, at least.

[khrykin]

Anyway, at the moment there's only utf8proc binary dependency besides boost and Qt, so let's not overthink this right now - I would just leave it as it's now on the master.