Consider switching GUI toolkits for iv

[lgritz]

The iv viewer is the only part of OIIO that uses Qt, which is an extremely heavy dependency, especially considering the tiny sliver of its functionality that we use. I didn't pick Qt for any special reason -- it just seemed to be a safe choice for a popular, dependable, cross-platform GUI toolkit when I wrote the first version of OIIO's iv in 2008.

We have talked before about maybe switching to something that would be a much simpler dependency to build and use. We've mentioned Dear Imgui or Nanogui as possibilities.

Let's use this issue to discuss, offer suggestions and debate the pros/cons, and track progress of the work.

As a reminder, when evaluating which toolkit to switch to, I think the considerations should include:

• Fuctionality: It must do the things iv needs now and potentially in the future, and not come with too much expensive baggage that we will never need.
• Cross-platform: It should be a given that we want it to work on Linux, MacOS, and Windows with as uniform an API as possible.
• Appropriately licensed: It needs to have an open source license that is compatible with our Apache-2.0 for the way we build and distribute OIIO.
• Widely available: As a dependency, it should be something that is easy to install, available in all the major package managers, or even easily "vendored" into our project.
• Easy to build: It should not be overly expensive to build from scratch.
• Dependable: It should be robust, polished, with an active development team. We don't want somebody's hobby project that has not been used on real products, or something supported by a single person whose availability to do continued support and development may vary.
• Known or worth knowing: It would be great if the toolkit was somewhat widely used so there are many people who already know it, or that people who don't know it would consider making the effort to learn it to have a positive ROI for them.

[EmilDohne]

I definitely agree that Qt is an (often) unnecessarily bloated dependency and reducing this bloat for the sake of build times and overall leanness of the application is always desirable!

I have to admit that I've only ever taken a cursory look at iv but I thought I'd chime in about imgui since I've built an image viewer in it before.

imgui as a library can easily be vendored as it's quite light and almost all systems will have some form of opengl or whatever other backend we use available to it. It is also entirely cross-platform and I've had success using it on all the big 3.

I think the main thing to keep in mind for it though is that, unlike qt, it doesn't come wheels included. I.e. for a file dialog you'd have to pull in another dependency like NativeFileDialog. I'm sure there will be other things that qt will ship out of the box which imgui will likely not.

One other thing, although I am sure you've already anticipated this, is that this will likely require a complete rewrite of iv. Since imgui is IM there is no such thing as slots/signals (although you could implement them) which would require a restructure of how the application is built up.

Overall I think this is definitely a non-trivial task but would be a good step forward. Then again though, there isn't anything inherently wrong with qt either

[lgritz]

One other thing, although I am sure you've already anticipated this, is that this will likely require a complete rewrite of iv.

Possibly true, but I think iv is really not a complicated app, so even a "complete rewrite" isn't necessarily an absurdly big job.

Overall I think this is definitely a non-trivial task but would be a good step forward. Then again though, there isn't anything inherently wrong with qt either

Agreed. It might end up being a perfectly reasonable conclusion that there are enough up-sides to Qt to make up for it being very heavy-weight and hard to build, and that any amount of real work to switch GUI toolkits is ultimately not worth the trouble. Or maybe somebody will come along and say "I've built more complex things with Imgui (or nanogui), this is no big deal" and just do the work and then we have it.