floooh/oryol-imgui

Hi - is there a better way to handle this?

drudru opened this issue · 12 comments

drudru commented

oryol-imgui/src/IMUI/imguiWrapper.cc

Line 31 in f2abc76

io.IniFilename = nullptr;

I just got my emulator running on Linux. I always forget to comment out the nullptr assignment.
Is this just needed for emscripten?
Doing the assignment prevents me from having my window positions saved in my emulator.

floooh commented

Yep, that was a quick fix to prevent ImGui from calling file functions on emscripten (as far as I remember).

I think the best way to fix this would be to add a new member to the IMUISetup function (for instance String IniFilename;, that way you could enable the window position saving again by setting a valid filename.

From looking through the Imgui sources it looks like the string pointer must remain valid as long as Imgui is alive, best way to do this would be to store the entire IMUISetup object in the imguiWrapper object (which pins the string into memory for the lifetime of imguiWrapper), and give ImGui the pointer to the string data in the copied IMUISetup.

I'm currently busy on my own emulator stuff, if you want to provide a PR I'm happy to merge ;)

drudru commented

Hey - will do - I'll look at this tomorrow 👍

drudru commented

Hi - 5 days later, I actually have some time to work on this :-)

I looked into this some more. How about a simpler option.
I think this would be simpler and get the job done for now. This eliminates big changes.

#ifdef ORYOL_EMSCRIPTEN
io.IniFilename = nullptr; 
#endif
floooh commented

Hmm don't like this, I don't want file accesses on native platforms either. I'll see if I can make some time for it in the next days...

drudru commented
floooh commented

Ok, I have committed an update which lets you configure the Imgui IniFilename and LogFilename. To get ImGui's standard behaviour (save to "imgui.ini") you would initialize the Oryol IMUI module like this:

    IMUISetup imuiSetup;
    imuiSetup.IniFilename = "imgui.ini";
    IMUI::Setup(imuiSetup);
drudru commented
floooh commented

Ah sure, it's just to have better control over IO operations in dependencies. A really 'proper solution' would hook into ImGui so that it doesn't call any POSIX functions, but instead delegates all IO calls to the application, so that I could have a chance to handle the IO in a platform specific way.

Sometimes this is not even possible, because a dependency might require synchronous IO calls (like the POSIX fopen/fread/fwrite/fclose functions), but some platforms only support asynchronous IO (like emscripten).

The next best thing to hook into the IO is to disable it completely ;) But I really want to do it in a way where one platform isn't a special case (because often that makes testing and development harder).

Also when I tested the ImGui serialization feature on Mac I still don't know where it actually wrote the .ini file :D

drudru commented
drudru commented

Just one more comment. I feel the same way about threading systems. It bums me out (sry in California), when a library picks one that is too platform specific or ancient. Also, dynamic loader APIs too.

But I have been guilty of the above as well! :-)

  • 👍1
drudru commented

Nice 👍