This looks great, thanks! Will give it a proper test as soon as I can - so far I've only checked on Linux and it does as expected (happily falls back to pkgconfig)

I really hope this can be merged soon, MFEKglif is still stuck on imgui-rs 0.7.0 and the branch has diverged a whole bunch yet again, I'd like to be able to upgrade it to 0.8.0 finally. (Cf. MFEK/glif#128 (comment))

hey @ruifengx this looks excellent, but I'm having some trouble in the CI here. You can see on my fork my current progress:
https://github.com/sanbox-irl/imgui-rs/runs/4611636419?check_suite_focus=true

No time pressure, but this is probably the last thing we need merged in before I can do a 0.8.1 patch!

@sanbox-irl vcpkg does not automatically install missing packages on build (especially when this build is triggered by Cargo as is the case here). You need a separate vcpkg install freetype in advance just like on Linux you need a dnf install (or apt install, etc.).

BTW, in the current design, we always try pkg-config first, and then vcpkg. So if both are available, the freetype available via pkg-config is always preferred. In such cases, to manually switch to the vcpkg version, pkg-config should be temporarily removed from PATH. I am not entirely sure whether or not this would be a problem.

Hmm! That seems less useful to end users then, huh? I was thinking this would work like how sdl2's vcpkg works, where it DOES fetch it for you

I think i'd confused this with their bundled feature! I'd definitely like to have that

For now, i'm going to merge this in and fix up the error messages, change some of hte feature gates (I'd rather you opt into vcpkg and freetype, rather than automagically getting both, since vcpkg seems to be much more common on windows) and then merge it in. Seperately, I'll make an issue for a bundled feature for freetype, which looks trivial for us to do

@ruifengx
Actually, adding vcpkg install freetype didn't work! I'm going to leave my work on this here, but here's what this PR needs to be accepted:

A. Add some testing for this feature to our CI, specifically in our Windows builds. For that, see lines 133-150.

1. Uncomment lines 133-135.
2. Remove the if guard on lines 145 and 149.
3. Somehow edit lines 133-135 such that this correctly builds!

B. Separate this feature into a use-vcpkg feature. I want users to opt into this rather than have it silently happen to them -- I'm concerned about cascading errors which will confuse people. So if you wanted to use just freetype and pkg-config, you'd just enable the freetype feature -- if you want freetype and find it with vcpkg, then use freetype,use-vcpkg. In the future, we'll have a "bundled" feature, which will be XOR with use-vcpkg, and I want to have that clearly differentiated now for that time in the future.

Let me know when you've got those done, and I'll merge it it, or let me know if you'd rather drop your own work on this, and when I'm back home for the holidays and have a Windows machine available, I can investigate this myself! (I'm on a Mac till the new year)

Hi @sanbox-irl, sorry for the delayed response. I see plenty of exclamation marks in your comments; please be assured that I get your frustration on a PR failing your expectation, and that the failure is due to complicated real-life situations rather than poor design.

That seems less useful to end users then, huh? I was thinking this would work like how sdl2's vcpkg works, where it DOES fetch it for you

I am afraid this is not the case, and I also believe generally it is not a wise decision to automatically install the dependency (in this case freetype) system-wide (however, I will definitely leave this decision to you maintainers of imgui-rs).

I think i'd confused this with their bundled feature! I'd definitely like to have that

To support a bundled feature, you will need a git submodule or something similar in your source tree (so that the dependency remain local, instead of conflicting with the global package installation on the target machine). In such circumstances, I believe the whole compilation process could be managed by cmake. Worth-mentioning though, using a bundled freetype rules out the possibility for custom compile-time options (to enable or disable various features in freetype), so I personally prefer a globally-installed customisable version for my specific use case.

Actually, adding vcpkg install freetype didn't work!

I will take some time investigating this tonight. I did confirm that the approach taken here works correctly on my PC before submitting this PR, so I guess there is something misconfigured in the CI process.

A. Add some testing for this feature to our CI, specifically in our Windows builds. For that, see lines 133-150.

1. Uncomment lines 133-135.
2. Remove the if guard on lines 145 and 149.
3. Somehow edit lines 133-135 such that this correctly builds!

OK, get it. I will try fixing this CI script and report my progress soon.

B. Separate this feature into a use-vcpkg feature. I want users to opt into this rather than have it silently happen to them -- I'm concerned about cascading errors which will confuse people. So if you wanted to use just freetype and pkg-config, you'd just enable the freetype feature -- if you want freetype and find it with vcpkg, then use freetype, use-vcpkg. In the future, we'll have a "bundled" feature, which will be XOR with use-vcpkg, and I want to have that clearly differentiated now for that time in the future.

I did not feature-gate use-vcpkg because pkg-config was not feature-gated as well, and I had some misunderstandings on your opinions about this. I agree a use-vcpkg feature is clearly a better design, and I would like to go further and suggest also feature-gating use-pkg-config. However, feature-gating use-pkg-config would be a semver-breaking change (because this update would break packages depending on imgui-rs with default features disabled). In my opinion, we should have three mutually-exclusive features: freetype-via-vcpkg, freetype-via-pkg-config, and freetype-bundled. (Again, this is just a suggestion, and I leave the final decision to you.)

Let me know when you've got those done, and I'll merge it it, or let me know if you'd rather drop your own work on this, and when I'm back home for the holidays and have a Windows machine available, I can investigate this myself! (I'm on a Mac till the new year)

I will try to get a properly-updated version in several days.

Oh hey, no frustration on my end -- your work is great and I appreciate your contribution greatly! I'm just of the age where I can't help but put ! on everything.

I did not feature-gate use-vcpkg because pkg-config was not feature-gated as well, and I had some misunderstandings on your opinions about this. I agree a use-vcpkg feature is clearly a better design, and I would like to go further and suggest also feature-gating use-pkg-config. However, feature-gating use-pkg-config would be a semver-breaking change (because this update would break packages depending on imgui-rs with default features disabled). In my opinion, we should have three mutually-exclusive features: freetype-via-vcpkg, freetype-via-pkg-config, and freetype-bundled. (Again, this is just a suggestion, and I leave the final decision to you.)

I agree with the above -- but unfortunately, we're a bit locked in without making a breaking change. I think perhaps in v0.10.0 we can make a major goal to have better freetype management for users. For now, just getting something that works for the majority of users will be sufficient I suspect.

Thank you for the effort -- I don't know nearly enough about this to get it done on my own, so your input is essential

I really really don't think it's a problem to have vcpkg required in this PR, then another PR to add both the use-pkg-config and use-vcpkg. It won't matter on Linux that vcpkg will never be available because pkg-config will work. I agree with the version of this PR as submitted by @ruifengx.

fair point, but I would like CI figured out before merge

Oh, that's not really a major problem. This commit doesn't touch CI. You need to add something like friendlyanon/setup-vcpkg@v1 (https://github.com/friendlyanon/setup-vcpkg) then add a command like this

      - if: matrix.platform == 'windows'
        name: Setup dependencies (Windows)
        run: vcpkg install freetype

Sorry, I know you are waiting or him to reply, I just want this fixed :-P

I actually did try that! If you see my above posts, I did exactly that, but it failed in the CI on my fork.

I didn't use that linked action though since windows runners come with vcpkg pre installed. That looks like it mostly handles caching -- does it also do some other work that might fix the issues I ran into?

And don't worry, any help is good help and appreciated @ctrlcctrlv

Oh, I'm sorry, I didn't understand fully the CI problem.

I think you need this also: https://crates.io/crates/cargo-vcpkg, which claims to interoperate with vcpkg

Then in Cargo.toml:

[package.metadata.vcpkg.target]
x86_64-pc-windows-msvc = { triplet = "x64-windows-static", dependencies = ["freetype"] }

Also I am doubting a little bit that the Windows GitHub CI comes with vcpkg.

The opencv-rust project, well maintained, installs it themselves:

https://github.com/twistedfall/opencv-rust/blob/master/.github/workflows/opencv-rust.yml
https://github.com/twistedfall/opencv-rust/blob/master/ci/install-windows-vcpkg.sh

RustDesk project also installs own vcpkg. Why do we think vcpkg globally included?

https://github.com/rustdesk/rustdesk/blob/b3e3f6151d537a009dbbb8ef695c6fe13fd45527/.github/workflows/ci.yml#L86

Their ci.yml also mentions $VCPKG_ROOT envvar.

Oh, I just found something interesting, even if you are right about vcpkg bundling with Windows GH CI, there is this in the vcpkg crate docs:

//! # Environment variables
//!
//! A number of environment variables are available to globally configure which
//! libraries are selected.
//!
//! * `VCPKG_ROOT` - Set the directory to look in for a vcpkg installation. If
//! it is not set, vcpkg will use the user-wide installation if one has been
//! set up with `vcpkg integrate install`, and check the crate source and target
//! to see if a vcpkg tree has been created by [cargo-vcpkg](https://crates.io/crates/cargo-vcpkg).

So you may have to run vcpkg integrate install, but really I think that it's more Rusty (is this a word?) to use cargo-vcpkg and not rely on any bundling, as who knows, they might drop it when M$ decides they have a new "solution" to problems solved on Linux almost 3 decades hence, as they tend to do every few years.

We should not use cargo-vcpkg in ci if we can avoid it, as cargo installing a binary in ci tends to be very slow

That's not a good argument because you can just cache %USERPROFILE%\.cargo\bin (Win32 version of Linux $HOME/.cargo/bin).

Caching is pretty dodgy at best, snd installing a program to avoid running a single command is… iffy, imo

There's nothing iffy about GH Actions caching, and if you don't trust it, you could upload a Win32 binary of cargo-vcpkg.exe somewhere, and fetch it on a cache miss.

Given it is only some 5MB, probably would even fit in a GitHub gist.

$ ls -alh ~/.cargo/bin/cargo-vcpkg 
-rwxr-xr-x 1 fred fred 4.9M Dec 25 02:01 /home/fred/.cargo/bin/cargo-vcpkg

There are benefits to users of using vcpkg Cargo.toml section, because it means upstream project CI will work too. If something is done ad hoc just in your ci.yml, such as what opencv-rust is doing, then that'd need to be copied by all.

Regardless, current imgui 0.8 is very broken on Win32, so I'd take iffy over broken, given it will only affect Windows CI build.

@sanbox-irl It seems I managed to make the CI pass: https://github.com/ruifengx/imgui-rs/runs/4631059708. Our first attempt was indeed in the correct direction, it is just Rust expects to be linked with 64bit static libraries with the MSVC runtime dynamically linked (thus the x64-windows-static-md triplet).

I will update the CI script first, and then start working on feature-gating use-vcpkg.

RustDesk project also installs own vcpkg. Why do we think vcpkg globally included?

The default software for the Windows runners is listed here, and does include vcpkg:
https://github.com/actions/virtual-environments/blob/7518d04a3a12a7fb369179b0e77d4d89c3db9b0f/images/win/Windows2022-Readme.md#package-management

Not sure when this was added, it might be a fairly recent thing thus RustDesk etc installed it manually?

have three mutually-exclusive features: freetype-via-vcpkg, freetype-via-pkg-config, and freetype-bundled

I think the bundling flag is a good convenience (maybe to do later), but I'm not too sure it's worth the minor extra complexity of having the two freetype-via- flags - is there a clear use-case for this?

My thinking is;

1. vcpkg-rs and pkg-config-rs are both quite lightweight dependencies (both small codebases with no dependencies, they just call the relevant commands as a subprocess), so shouldn't add any significant compile-time overhead
2. It seems very unlikely someone would a) have both installed, and b) have freetype available in both, and c) care specifically which one is used

Meanwhile you can add to cimgui_manuals in generator.lua the function to be skipped in generation

[...] we do that but we don't grab random commits -- we're grabbing releases.

For imgui-rs 0.9, I reckon we can ~manually backport the ocornut/imgui@980deb4 fix to the vendored copies of imgui

However in 0.8 it's a bit trickier as that version still uses the git-submodule, but if tweaking the cimgui generator would work, then that sounds like a good solution here

@sanbox-irl

how is this still open

should i just port my code to egui and be done with it because "we don't use random commits"

imgui-rs 0.8 has significant unfixed breakage and really i'm starting to doubt this project's priorities…

another option i could take is to PR a way to replace your entire imgui-sys with a link to libimgui.so. @ocornut feels that dynamic links to imgui are almost always overengineering (cf. ocornut/imgui#980 (comment)) — incredibly we may have found the exception

My post suggested that i encourage people (expectially c++ users) to compile themselves as it allows configuring stuff like compatible math types. Binaries built by others won’t do that. Do whatever works for you.

A friend of mine started rewriting cimgui because it appears like in its current iteration it became a bit of a bottleneck for progress for users of non C++ languages, if you are interested we can share the wip repo. (Our version currently output enough metadata to output headers with full comments etc)

yes, very interested, as I experimented myself already with compiling libcimgui to .so

i believe it works

i'm frustrated with lack of progress in this project, so if i could PR a way to tell imgui-sys where to find a .so and just call cargo:link then all this back and forth over imgui version becomes something i can do internally at MFEK

so if i could PR a way to tell imgui-sys where to find a .so and just call cargo:link then all this back and forth over imgui version becomes something i can do internally at MFEK

The better way to do this (which doesn't require you wait for a release even) is to just override it in the [target.$target.imgui] section of a .cargo/config.toml (note: not cargo.toml), as documented here. https://doc.rust-lang.org/cargo/reference/config.html#targettriplelinks. The key to use for the links part is from https://github.com/imgui-rs/imgui-rs/blob/main/imgui-sys/Cargo.toml#L12.

More broadly, imgui isn't ABI stable, so linking to it as a dynamic library isn't something we really want to expose IMO, since it could easily be unsound. Statically linking is good for 99% of cases, and the remaining 1% can just override in their .cargo/config.toml.

it's not something you want to expose at all, or not something you want to expose by default?

oh i see what you're saying. with that [links] i could link a dylib libcimgui.so with few lines in toml, no need for PR here. i get it

The upstream fix for this is part of imgui v1.87 onwards - so I think the most pragmatic approach to (finally! 😓) getting this out is:

1. Release imgui-rs 0.9 asap, pretty much the repo in it's current form
2. Update the bindings to latest imgui release (1.88)
3. Merge this PR
4. Release imgui-rs 0.10

Glad to hear this! I could rebase this PR onto the latest main to resolve the conflicts. Please inform me when it is appropriate to do so. (Presumably after Steps 1 and 2 are done?)

@ruifengx Sorry for the protracted delay, but.. I think this is now ready to rebase (v0.9 is out the door), if you have the time!

I have just rebased my fork to main. I have confirmed on my Windows 11 PC that it now passes all the tests with cargo test --features docking,freetype,use-vcpkg.

Note: To link properly with MSVC for docking + freetype, I had to modify cimgui.cpp. I need to stub igImFontAtlasGetBuilderForStbTruetype if IMGUI_ENABLE_FREETYPE is defined, because otherwise the MSVC linker will complain about non-existing symbol. If my understanding is correct, the fix upstream in cimgui (cimgui/cimgui#193) requires regenerating the C binding every time the feature combination is changed, which I believe is not compatible with the settings here. Please do confirm this change is acceptable before merging.

Ah I think that manual edit to cimgui.cpp will no longer be necessary once #688 is merged (the upgrade to 1.89.1) as the upstream fix ocornut/imgui@980deb4 is persent in this version

The upgrade PR is 99% done, so should be merged in a few days (barring some delays for the Christmas holidays) - then I think we can finally merge this - thanks for all the work!

Good news for users of this library but I invested in switching MFEKglif off of imgui-rs, and onto egui, primarily due to this bug and now that that's set in motion won't claw it back.

• Fix scaling issues lucasmerlin/egui_skia#3
• Add OpenGL/Vulkan SDL2 support lucasmerlin/egui_skia@2787071..lucasmerlin/egui_skia@70ffaeb

Not mad about it, just saying that maintenance decisions have consequences downstream :-) perhaps this one is even fine / worth it on both sides.

Thanks @ruifengx - merged this with the in-place edit, which will be effectively reverted via imminent #699