August 10, and ideas

[ocornut]

August 10 is the date last year I put ImGui 1.0 online, following a month of preparation!
I will need to step back a little from ImGui and I thought the first year anniversary would be a good date for that.

I really enjoy working on it and I have hundreds of ideas of ways to move it forward. Then reality hits: I've been slowly consuming my savings putting time to work on this and other free projects. At this point in my life I really need to try to focus on finding something I can make a living of and this means I need to put some things aside, free up time and reduce my already charged cognitive load. Sustainable game development is enough of a lottery that I can't afford to make it harder for me.

My hope was that some of the larger companies using ImGui would be able to contribute to the Patreon up to a point where I could justify spending a few days a week working on it, but it is probably not going to be the case. I am very very grateful of everybody already helping with the Patreon. It wouldn't be reasonable to expect more and I certainly don't expect individuals to add more to the pot.

So while I won't abandon ImGui and I know myself well enough to know I'll always be doing things on it, I need to set a date to make a mental transition of softening my involvement. So instead of waking up thinking "shit I need to fix this bug or add this feature" I'll be more relaxed about it. I may come back to focus on it occasionally depending on my situation.

Omar

Development wise, some upcoming themes I have in my mind:

• (DONE!) Finish the anti-aliased branch.
• (DONE!) Which means re-factoring the rendering data to be more future-proof. Switching to indexed rendering already broke rendering in the AA branch so it is the perfect time to do that transition. We should be able in the future to provide high-level information on windows so that virtual canvas, networked output is easier to work with. Also consider the possible transition to use a dynamic font atlas, perhaps the user would get e.g. a texture dirty-rectangle.
• (DONE!) The current columns implementation is currently performance-poor because it keeps pushing primitives in submission order with different scissoring settings, whereas each column should append to its own list and they are merged-flattened at the end of the column set. One advantage of switching to indexed rendering is that it is now much easier and cheaper to do that. I want to think that feature through just in case it has an effect on the rendering data (it might not) so all the breaking changes can be done once only.
• Add a framework for testing. If more people have to work on ImGui testing needs to be more thorough. I don't know what form it would take yet.
• Add a framework for generating screenshots/animations for given pieces of code. This is probably going to be done along with the "testing" framework. I would like the ImGui documentation to be a very visual, well organized listing with C++ code on one side, screenshot (or animated GIF) on the other side and tags + commentary. I think this will easily convey a lot of ideas and tips about ways to use ImGui.
  Update: I've created some helper to help me take manual screenshots and its been very helpful in the past few days. This will probably evolve into such framework.
• (DONE!) Various improvements with font (Add font fallback support, just like what windows does. #182 AddFontFromMemoryTTF transferring ownership #220 Using Icon Fonts in current Font #232 Font character spacing settings (GlyphExtraSpacing) #242 are all related, the key is figuring a way to do the initialisation that is flexible enough). And considering making the texture a dynamic atlas (this later part is much less a priority).
• Allow all "value - label" widgets to be displayable in a variety of combination (e.g. "label widget", "label\nwidget" with variety of expressive layout options and alignments. Devise better methods to express and manipulate the size and alignment of one or multiple widgets. Currently the PushItemWidth(...); Widget(); PopItemWidth() idiom is way too verbose. Enable simpler and better horizontal layout.
• Resizing separators, a way to separate e.g. two child windows and resize them. That would be a more flexible generalization of the concept used by columns.
• Better columns, sizing options, columns header, scrolling with non-scrolling headers, sorting, re-ordering. It's all sort of feasible but should be natural first-class citizen.
• Better methods to handle simple alignment issues. The checkbox in the demo window with "No title bar" "No resize" etc. is a pattern that is hard to solve perfectly in one pass with the current available features. The approach of ImGui for some problems like this one is often "who cares just add a constant" but it'd be nice to have extra layout features to allow for it more elegantly.
• Shortcuts for menus and a general shortcut system.
• (DONE!) Keyboard navigation and usage.
• A generic iterator/data access scheme so that API like Combo or ListBox can be used with sparse list of value (currently Combo assume linear sequence so the user needs an extra level of indirection if their value are sparse).
• And the visual redesign..

I don't know when those things will be done. Probably not by August! if you feel like helping with something let me know!

[Pagghiu]

Hi Omar,

I have been reading this post and I want to comment both the first and the second part.
Regarding the first part it's clear that the time you can spend on improving the library is proportional to the money you can make with it.
Have you already thought of changing the way you're "marketing" the library?
Let me try to explain what I mean.

0. Imgui needs a website that should at least contain latest up to date downloads, donations links, cool shots/video, roadmaps, who's using it etc.

1. You may be under-estimating the power of this library, it's not just for debug visualisation or game/tools/editor UI. I think what I was able to achieve in a few months of usage/customisation is really cool. Have you seen my latest shots at Gallery: Post your screenshots / code here (PART 1) #123 ? Probably a video instead of some shots would make it more clear.
   I see IMGUI as a general cross platform UI library. The current showcase example is cool, but spending some time in building some "real world" examples would open a whole new world.

2. Put some effort on making the demo/shots of the library more visually appealing.
   I'm sure this will increase usage A LOT, and more popularity, more possibility of money making for you.

3. Ask for money on specific features. Less Patreon and more Kickstarter. Something along the line of:
   "Feature proposal XYZ: Create the TextEditCheckboxMultiline Widget" - Target: 500$
   When target is reached, you will implement it in 1/2/3/whatever months timeframe was stated in the proposal.
   A big company that absolutely needs feature XYZ will be a "sponsor" for it, more or less like LuaJIT (see http://wiki.luajit.org/Open-Sponsorships )

4. Spend some time to integrate and keep up to speed some cool forks I've seen around here to expand functionality (the remoteimgui is really cool)

5. Make some ready to use samples that show integration with other UI frameworks (I've personally done it with MFC on win / Cocoa on mac), without requiring strange "game programmer" libraries like glfw etc.

6. Create wrappers for other languages like C# so that people can use it in Unity or other cool engines from webgl/javascript via emscripten!.

7. Ask for help! Try to write down a proper structured roadmap and/or thing you would like to do in a way that a contributor could try to send a meaningful pull request to the project.

Regarding the technical part I think the priorities should be

• Font handling: this will make the ui extremely more appealing and flexible
• Visual Redesign: this is important to show the power of imgui.
  Just adding some colors, with icon fonts and using a proper text font makes everything so much cool :)
• Widget Alignment: we've discussed this a few times even if I've always been able to place controls where I want with some more ad hoc verbose code.
• Everything else in any order.

[extrawurst]

@Pagghiu at least wrapping (point 6) is already done in form of a c-api (https://github.com/Extrawurst/cimgui) using this is easy from most of the other languages.

[ocornut]

They are all good ideas but basically you are suggesting I spend double the amount of time on it! I am already putting myself in trouble often putting 15-20 hours a week on it. There are times where I would have no problem putting that into a hobby project but not so much right now (the peek of availability for hobby projects is being salaried / with savings and being single. I'm not salaried I have little savings and I'm not single!). Just so many things adds up, answering support (here or via e-mail), lots or decisions to take, small or architectural, keeping the thing optimised and relatively sane. Like every software project most features that appears simple or minimal always end up taking three times the amount of work (lots of thing would be much easier working in a vacuum but here I can't just break everyone's code all the time).

I also fully agree that the better visuals will attract more people. I feel that strongly and I keep hearing comments about the visuals. I will work on visuals (and I am) but the library needs to grow at controlled pace to contain the influx of requests and desire from extra users. If the library looked beautiful one year ago I would have had a hard time to make the changes I needed to make during the year. People would have looked at it and be disappointed. It would have lacked features and I would have had to break it every three weeks. I need to get the features stable to build the visuals upon them. Better visuals are planned but several things needs to be sorted out before. If I just rush into visuals right now it would jeopardize a lot of other factors.

Then I think people under-estimate the tight correlation between layout features and performance and visuals there is. The mockup in #184 is cool but basically break a million assumptions and techniques used by the code. So many little things about the design where chosen based on implementation or performance and as you try to make the design tweakable you have to tackle each of them. ImGui is sitting in a tight equilibrium that's also the reason it's so simple and small.

I need to protect 1/ ease of use and 2/ performances.
It's important in that process that we don't lose the quick & dirty usage possibilities of the library. On Tearaway or Dreams or WiLD they both have dozens of tools created by different people. They are mostly adhoc and a bit clunky but all extremely useful and ever evolving and a core part of the day to day development process. If you make the library look super neat it has side-effects on building interfaces. e.g. if your interface uses nice icons everywhere then suddenly you may feel like you can't add a button right now because you don't have the icon for it. So it's important to still allow for a programmer to quickly add an ugly unaligned button here and here for the sake of productivity and not be dragged away in visual considerations. I need to allow for both worlds to cohabits.

0. Imgui needs a website that should at least contain latest up to date downloads, donations links, cool shots/video, roadmaps, who's using it etc.

All of that is already on the github page in one way or another. Yes, it should be presented better and a web page would help but again it is lots of extra work to present things.

1. You may be under-estimating the power of this library,

I think it shines more as an embedded game-development library to create ten clunky-looking-tools a day rather than to create precisely designed and layed out tools. The former was lacking a solution and I think ImGui full-fills some of that. The later has already many solutions available (even if they all have their unique issues).

I think it's great that you and others e.g. ProDBG are using the library for things it wasn't meant to target initially, but the more I go this way of trying to emulate desktop apps, the more requests and features will come. It's way far off what most people expect of an UI library like QT for desktop apps. The possibilities are endless here and I could be spending an eternity full-fulling them. So I'm torn between appreciating that those uses are helping to push the library forward, and the fact that they are putting an infinite load of extra work on me :)

3. Ask for money on specific features. Less Patreon and more Kickstarter. Something along the line of: "Feature proposal XYZ: Create the TextEditCheckboxMultiline Widget" - Target: 500$

I think you are over-estimating the user base here.

• First I don't think anybody currently using ImGui would have put $500 on line for me to add a features like the multi-line text editor.
• Even if they did it would not have paid for my time if we are considering a programmer rate (but I am happy to be flexible with that) .
• Even ignoring the cost new features are the easiest to sell and market but the majority of the time is doing maintenance, support, optimisations, tweaking, architectural decision, documentation. And those are invisible and even harder to sell. The way a traditional company would handle that if they would inflate the cost of the feature (so the $500 above become $1500) to cover all the side things that need to be done.
• Finally, unless it really took off a commercially stable project backed by companies, I don't think it would be super healthy to aggressively try to monetize features and make this github a giant feature market. I'm sort happy to serve hobbyist and independent developers and the general interest. Yes I would implement any feature paid for (none so far) but I don't want to be waiting for an eventual fund to get moving and add things that people want. I think it'd be hard to juggle both systems together.

6. Create wrappers for other languages like C# so that people can use it in Unity or other cool engines from webgl/javascript via emscripten!.

Btw I added a link to Extrawurst' c-api from the readme. I am a bit torn again here because ImGui API was designed closely for c++ and without default parameter and function overloading a lot of it gets really confusing or tedious. I don't think ImGui would make as much sense in other ecosystem like .net or webgl.

Again none of the ideas are bad but they are all essentially asking for me to "spend more time on it" so I don't know what to take away from that. I will look into setting up a roadmap.

AA and better font support are probably close so those will give a bit of a lift.

[adamdmoss]

Personally I approve of any steps that omar wishes to take to avoid having imgui become a great burden or a chore - that would be the worst thing for everyone. I think having a slowdown date is a good idea.

[unpacklo]

You've done a fantastic job so far and the progress made over the last ~1 year has been pretty amazing! I've told you a few times before, but I need to say it again:

Thank you very much for all the hard work you've put into this and putting this thing out into the wild for people to use! ImGui really has kind of saved my ass when it comes to working on my game. It was a constant struggle of how to get things to be interactable and iterated on in the engine. My only tool before was completely text based console + hacked together "UI" which amounted to in game debug draws and hardcoded input handling... not pretty and very time consuming, but ImGui changed everything for me.

It's a little disappointing to hear that you haven't been able to quite make this thing a full-time gig, but I still have hope that you can slowly build more momentum and maybe you'll be able to dedicate more time to it later.

Have you thought about having a few maintainers to help you out with stuff? Maybe not implementation-wise (seems like ImGui is not yet mature enough to have a bunch of people writing code to trunk) but at least to help out with checking/categorizing issues and responding to newcomers who have basic questions?

I think it shines more as an embedded game-development library to create ten clunky-looking-tools a day rather than to create precisely designed and layed out tools. The former was lacking a solution and I think ImGui full-fills some of that. The later has already many solutions available (even if they all have their unique issues).

This is commandment number one of ImGui for me! I use ImGui to help me get things done, and I am willing to let things be quick and dirty now if it gets me to producing good work more quickly. No doubt, improved visuals are important and I think will hugely benefit ImGui in the future, but it should not lose sight of the fact that ImGui's power is to be a hammer.

[Pagghiu]

Omar, I really appreciate the time you've spent answering here.
I can see the reasons that are leading to your decisions and they seem very reasonable to me.
I still think that IMGUI (I see it more as a philosophy) could really become a competing product, but of course it needs some investment, as you're pointing out. I've been using many different UI systems in the last years in some real products and the amount of burden that where adding to develop and deploy even simple apps was unbelievable to me.

Qt SDK is several Gb (per platform), when you hit a bug you often have to wait for months before it gets fixed. If you want to fix-it (obeying the LGPL or buying the commercial license) and build it, good luck. They use all kind of DSL Languages (QML? JS? to work with C++?).
Deploying tools trying to track all needed .dlls and plugins are often out of date or not working (maydeployqt....aaaargh). And you end up with 30 mb of unneeded dlls for an hello world application.

I've gone through the path of making "web-apps", core in C# or C++ and UI in JS/HTML5...Endless hours trying to figure out different browser problems or this/that JS framework problems. And exposing everything as network service is not an easy task, nor very performant.

I've also used Xamarin for an older product, with a terrible resulting experience. They always look for the latest and greatest feature and they give very small priority to bugfixing. And of course bridging c++ and c# was a constant source of problems and inefficiencies. Maybe they will improve with the opensourcing of .net but hey, we're bringing an entire VM+runtime here so good luck with that.

With IMGUI I am able to add 1 .cpp file to my project (even 5 or 10 wouldn't be a problem) and I have 80% of what I had in all the other systems, still being multi-platform. And I know I can code/customise the remaining 20% (that I actually did something as you've seen).
The code is so small and concise that I can fully understand it and customise it to single pixel.

I cannot do anything with any of the other systems, as I would need one week just to understand how to BUILD them, let alone make a modification :)

The problem with existing UI Systems is that they try to be much more (from string handling to File IO/networking, xml, json oh my..) and in the end they lock you inside their system that you cannot leave in any way without throwing away a lot of written code.
My choice was to internally develop over the years backend code for everything not GUI using some small, self contained and single purpose open source library (mainly LibUV and some other single file libraries like stb, miniz/zlib etc.). IMGUI is perfectly orthogonal to this philosophy and closes the circle to create a complete software product.

In my opinion the only way to survive in a world where every couple of months a new platform arises to keep your UI and Backend code completely separated, always being able to replace the first.
Many bigger companies (Microsoft with Office, Dropbox with their product) are doing the same, but they rewrite the UI for each specific platform for optimal user experience.
For most of my company projects this is not necessary (for now) so IMGUI is a really great solution.

My 2 cents, I'm sorry to be maybe a little off-topic, I should probably write a blog post to express my thoughts on this large topic, rather than polluting this github issue ;)

I will try to show what I am doing (I will be porting some other projects to IMGUI soon) and continuing to share my experiences here, so that they can be helpful.

Thanks again for all you hard work.

[tamaskenez]

I just want to second @Pagghiu's opinion about the importance of the cross-platformness of ImGui.

I have yet to actually use ImGui but the sole reason I'm considering it is that it provides a nice, cross-platform GUI solution from WinCE to MacOSX.

About the features: for the outsiders this imgui-movement is generally known as some quick&dirty thing to put up some buttons and labels. I was surprised to see how far it has been developed. I could even write an email client in ImGui.

[ocornut]

Thanks for the kind words everyone. Yeah, portability is the major benefit and requirement that got me started. I started ImGui for the PS Vita and then on to PS4 and needless to say none of the supposedly "portable" solutions like QT are remotely able to run on those platforms.

I was always into writing "live" tools. My first game for the DS had a decent live editor PC-side ( https://www.youtube.com/watch?v=MS9kqrGt_bM ), we used QT only for a few things (most of the code was related to the OpenGL view) but even for that QT was a problem when we tried to get very dynamic widgets, and it forced callbacks and state sync everywhere. I remember being stuck with a particular version of QT because after upgrading everything would run very slow which was hard to believe. Probably did something wrong but it's always hard to know what. Anyway.

[ocornut]

@Pagghiu I've tweeted a bit of your message, seems like it resonate with people
https://twitter.com/ocornut/status/629792897328529408/photo/1

I'm still cautious because I think people are expecting too much of ImGui. It's still pretty much a "I don't care so much about layout" type of libraries and there's limitations coming with that. But I'm happy it can be helpful and inspiring to many. (and that I can use it myself =)

[Pagghiu]

Great tweet!

Regarding the layout as in imgui you basically define stuff in a "functional" fashion it's always easy to write dependant expressions that size something depending on previous stuff...90% of general desktop gui patterns can be implemented this way, and for the remaining 10% well, you can simply go with absolute coordinates (SetScreenCursorPos etc., I've done it in a couple of places).

I think that's the greatest thing about open sourcing something...someone will always try to hack your code and do the things you couldn't imagine!

[ocornut]

Today ImGui 1.0 is 1 year old, yippee!
kthxbye!

[emoon]

Thanks for all the hard work :)

[brucelane]

joyeux anniversaire ImGui !