Please don't force imgui into a subdirectory about imgui-addons HOT 7 CLOSED

Right, i was drunk i think. I included it in the build system as well as in my code.

from imgui-addons.

ImGui-Addons/FileBrowser/ImGuiFileBrowser.h

Line 4 in f7b72fb

#include <imgui/imgui.h>

imgui.h lives in the root of the imgui file structure.

Rather specify the include dir through the build system.

Yo, I finally realized why I did this. Since it's pretty common to treat Imgui files as your project files, they are usually copied within the project directory inside a folder named imgui and not really used as a 3rd party library. And I don't think anybody includes the directory path of folders within their project directory in their project configuration. Usually you just mention the root-level in the IDE and then access every other thing relative to it.

So the IDE has the project root directory information. In order to access imgui files (in a folder named imgui) lying within that directory we'd have to do #include "imgui/imgui.h"

So I'm thinking of reverting this change back to how it was. But there was a problem with the workflow file. Anyway to trigger the workflow without actually committing to master?

from imgui-addons.

I tend to disagree. You can't expect everybody to have an 'imgui' dir. If you download the releases you end up with a imgui-$VERSION dir. If the imgui source would have an imgui dir you would be right but otherwise it's left to the build system to specify where to find the necessary files.

Take this CMakeLists.txt for example: https://github.com/rokups/ImNodes/blob/26c6dbc981da747eb49f2d9f29efe808bd22ab7a/CMakeLists.txt#L32

from imgui-addons.

Ow the example cmake downloads the imgui release and unzips it. Therefore you would have imgui sources in the imgui-$VERSION dir. You wouldn't be able to use the FileBrowser addon then unless you would symlink a imgui dir.

from imgui-addons.

Nobody needs to download imgui separately. There is a reason why I went with the submodule structure. If you clone the repo recursively, you'll end up with all the imgui files inside imgui directory. Cloning recursively is faster than finding the said imgui version manually in the main repo if it's not uptodate.

Secondly even if we assume that somebody downloaded the required imgui version manually hence his/her imgui files are in any folder named XYZ. Assuming that he will put imgui files together with his project files (which is the usual way to work), that guy is gonna put that XYZ folder inside his project folder. And as far as I know, you don't usually provide reference to paths inside the project directory just the root level. So he'll have to access the imgui files like XYZ/imgui.h anyways.

So am I missing something?

from imgui-addons.

I'm not sure I can follow you. Are you saying you want to have two directories with potential different versions of ImGui?

From my perspective people are using this FileBrowser addon in their project which is probably already using ImGui. The FileBrowser addon is probably in a different directory in that project than ImGui. So checking out imgui with this addon is not advised then.

Take a project I'm working on as an example. It has the FileBrowser addon in the ext directory. ImGui is somewhere else as well as other addons. See: https://github.com/hku-ect/gazebosc/tree/master/ext

from imgui-addons.

Man just leave it xD It's too much of a hassle. I was originally thinking that people include imgui files in their project like #include "XYZ-folder-name/imgui.h", but some big projects also do what you are saying i.e. put all the third party libraries in a folder named third-party or something then add references to the paths to every library folder inside that parent folder so you are back to including like #include "imgui.h". To each his own, I guess. Anyways nothing that big of a problem, will leave as it is. If anybody wanna change, can change himself. It's just 2 files.

Thanks for the feedback tho, appreciate it mate.

from imgui-addons.