search

ocornut / imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
MIT License
61.29k stars 10.33k forks source link

10 years of Dear ImGui (long post) #7892

Open ocornut opened 3 months ago

ocornut commented 3 months ago

10 years of Dear ImGui 🎉

On August 11, 2014, I published v1.00 of Dear ImGui on GitHub. I thought I would take the occasion to reflect about it, share some data points and stories, and generally think about what I want and need.

No big fantastic announcement here, mostly a series of stories and thoughts. This is a long read. Please be mindful this may be a bit unstructured and going in varying directions. I may improve and rearrange this document over time.

I would first of all like to thank all users, contributors, supporters and commenters who helped and contributed to Dear ImGui and its community.

I will keep trying keep Dear ImGui sane, friendly, efficient, relevant.

🙏 Please be kind to not use this thread to request or discuss features! It would be unmanageable. You can search or open new issues if needed! But feel free to reply with your impressions about this post or about Dear ImGui in general! Thanks!)

INDEX

(from https://github.com/ocornut/imgui/issues/7892#issuecomment-2291432206)

1. Statistics / Some Numbers

2. The Story Of Dear ImGui / Early Timeline 2.1. My Early Programming Experiences & User Interfaces 2.2. Stumbling On The ImGui Paradigm In Japan 2.3. Media Molecule, Writing A New Library 2.4. Publishing (Dear) ImGui 2.5. Focused And Funded Onward!

(from https://github.com/ocornut/imgui/issues/7892#issuecomment-2291434266)

3. What Went Right 3.1. Increased Adoption 3.2. Trust / Consistency / Long-term Maintenance / Nurturing A Culture Of Support 3.3. API Ease Of Use 3.4. Listening, Asking, Eavesdropping 3.5. Runtime Performance 3.6. Lack Of A Build System Is A Feature 3.7. Catching User Mistakes 3.8. ImGui Demo Vs Traditional Documentation 3.9. Backends 3.10. Continuous Integration 3.11. Test Engine And Test Suite 3.12. A Web Of Searchable, Persistent Interlinked Information + Neat Commit History 3.13. Fun Community Events 3.14. Great Third-Party Ecosystem

4. What Went Wrong 4.1. Being A Janitor + A Cop 4.2. Answering Too Fast 4.3. Drowning In The Attention Economy 4.4. Not Accepting More Contributions 4.5. Perception Of Project Stagnating, Where Are The New Cool Stuff? 4.6. General Burnout, Lack Of Focus, ADHD 4.7. Unplanned Career Change 4.8. Maintaining Backends 😭 4.9. Lack Of Visibility Of Some Features 4.10. Discord And Fragmented Communities

(from https://github.com/ocornut/imgui/issues/7892#issuecomment-2291436235)

5. Strategy Of Pacing Growth & Crowd Control

6. Prioritizing Large Tasks Again!!!1 6.1. Better Font Support 6.2. Better Text Functions 6.3. Better Support For Dpi Scaling 6.4. Tackling Some Of The Main Docking Issues 6.5. Rewriting Docking (v3) 6.6. Rewriting Multi-viewports (v2) 6.7. Rewriting InputText (v2) 6.8. Better Better Styling (v2) 6.9. Better Layout Helpers 6.10. Better Support For Idle Mechanisms

(from https://github.com/ocornut/imgui/issues/7892#issuecomment-2291436815)

7. Funding 8. How To Help

ocornut commented 3 months ago

1. STATISTICS / SOME NUMBERS

Features:

Test Suite:

Third-party:

Code size:

Open tasks:

Contributors:

GitHub stats:

Users:

Sponsors:

Quite a success!

Dear ImGui 1.91 does a LOT more things than 1.00 did. And by nature, the API has a large surface contact with the user application. So it’s only natural that some of the numbers would grow.

I don’t want to imply that "more code" or "more functions" is necessarily a good thing! As a core guiding principle, I always resist adding unnecessary code: I always try to delete, remove, compact, simplify when I can. I spend meaningful time doing this. New things are always being added after careful consideration of how I could avoid adding them. I believe that Dear ImGui brings incredible value relative to its complexity and code size. I will stay careful keeping the codebase neat.

2. THE STORY OF DEAR IMGUI / EARLY TIMELINE

2.1. MY EARLY PROGRAMMING EXPERIENCES & USER INTERFACES

As a 12 year old in 1992, in-between playing video games I discovered programming with MS-DOS 4.0’s BASIC. I had no access to the Internet back then. Barely borrowing books at the library which I would try to xerox, and yet not quite understand. Tinkering but didn't make great progress until 1996. Was mostly playing video games :)

My first released software (URL) in 1997 was a frontend/shell for MS-DOS written in Turbo Pascal... effectively a text-mode based user interface:

url6 url2

My second non-trivial software (MEKA) in 1999 was a Sega 8-bit emulator also for MS-DOS. Back then it was mostly known for the quality of its overall user experience and its graphical user interface. The concept of a windowed GUI for an MS-DOS era application was rare back then. MEKA had a fun little GUI with theming, gadgets, easter eggs, memory viewers, tile viewers, text editing etc. All in a custom UI system. Predating MEKA were Icer Addis's spectacular emulators Nesticle/Genecyst/Callus, and then Archeide's Snemul. I assembled blurbs of code I didn't fully understand, added lots of glue and neat ideas, and through sheer passion and patience turned the whole package into a product that had a unique touch.

meka

My first work experience was at In Utero (1999-2000), exactly one day after receiving my high-school diploma. I am a volunteering intern, the youngest person in the room. They are building multi-platform games (Dreamcast/PS2 era). Among other things they had built an elaborate, multi-purpose content creation tool called "ISAAC" which was my first foray into larger tooling UI.

evil_twin-tooling

My next meaningful project was Soul Bubbles (2004-2008) for the Nintendo DS, for which I wrote a large portion of the engine, gameplay and custom tooling in Qt (cool video of the editor and its real time editing).

sb-celt1

All those tools were using classic "retained-mode" graphical user interfaces, as it has been the dominant paradigm for decades (you may read my half-assed article about the IMGUI paradigm if you are not sure of the difference between RMGUI and IMGUI).

Everything was and always has been custom in-house technology, as it was generally the case at the time. Up to this day I have never seriously worked with UE or Unity for more than a few weeks.

2.2. STUMBLING ON THE IMGUI PARADIGM IN JAPAN

In November 2008 I landed in Kyoto, Japan to start working at Q-Games and what would become PixelJunk Shooter. The in-house game editor used a useful but very crude, black and white looking UI system called "simgui", written by Atman Binstock. It is the first implementation of an IMGUI that I stumbled on. Atman used it for PixelJunk Racers for which he was the main programmer. The tech got used by PixelJunk Monsters and PixelJunk Eden (all great titles!).

Atman at the time was friend with Casey Muratori, who is the person coining the term "IMGUI" with his seminal 2005 video “Immediate-Mode Graphical User Interfaces” and later on the Molly Rocket forum (2007 mirror, partial 2013 mirror). Shortly after Casey's video, Sean Barrett (known among other things for the stb libraries) published an article in the September 2005 issue of Game Developer Magazine (Page 34) + accompanying sample code. Atman was part of this group and I assume got into writing his implementation based on discussions with those two (along with Jonathan Blow who the third person credited in that GDM article). The Molly Rocket forum gathered people discussing concepts of this paradigm and trying to push it forward. I believe Unity’s own IMGUI implementation, which has been powering its editor, stemmed from Aras Nicholas Francis (corrected 2024-08-17), an early Unity founder, lurking in that forum. (amended 2024-09-03 with mention of Sean Barrett who was missing from initial post)

At the time, the version of simgui that I inherited was very simple: windows, buttons, sliders, text printing, basic plotting and not so much more. Like many people who first stumbled on IMGUI before it became more popular, I was initially surprised by this system, as it didn’t align with my earlier RMGUI experiences. The API for those simple features was very close to what Dear ImGui does today.

Shooter-crop

Anyhow, we had simgui around and started building the game editor using it. I’m mostly working on gameplay logic but the tools are needing some love and I generally like writing tools so I went ahead with it.

I guess it was probably about a month or two after I arrived: content creators had to constantly pick assets from a multi-page list, by painfully clicking "next page" many times, and the current page wouldn't even be saved. I implemented a text box control and made it possible to filter the list. Overnight it felt like everyone's productivity doubled! The truth is, when creating a game and especially one with new custom technology, there are so many things to tackle. Between the beginning and the end of the development cycle of a new engine or new IP, it is typical that productivity grows by several levels of magnitude. Tools are improving, team members are also improving their mastery of the tools. But I believe that this little change ignited a spark that reminded me how with better tools we can really empower our content creators and improve the game. I was hooked into making tools again.

After Pixeljunk Shooter I worked on a project which initially went by the codename of PixelJunk LifeLike (then eventually released as PixelJunk 4am - bonus second video). It was a little bit experimental. During the first half of development the creative director wasn’t often around, I was kinda lacking a solid direction and mostly left alone. So I made the mistake of pivoting toward "let's aimlessly make a generic content creation tool that someone someday will use!" and ended up in a whirl of tooling UI procrastination. This at least had the benefit of taking me on a path of thinking about desirable tooling UI features and finding ways to implement them in the simgui library within its specific constraints, which were new to me. I think this is where I first got the idea of e.g. the id stack, which I needed to implement tree nodes. This is where I started thinking about styling, polishing the UI a little bit. And many other things. I stumbled once or twice on the Molly Rocket forums but mostly did my own thing based on the seed Atman had planted. By the end of my era at Q-Games, I had written a full-on debugger for the GameMonkey scripting language we used (which apparently got carried on and improved and used up to The Tomorrow Children).

Lifelike

2.3. MEDIA MOLECULE, WRITING A NEW LIBRARY

In April 2011, I joined Media Molecule in Guildford, UK, to start working with a small team on a new IP for the yet unannounced PlayStation Vita. It ended up being released as Tearaway (a weird, crafty, positively deceptive game which IMHO may be among the most interesting games on the Vita, but I am obviously biased).

The game went through many large design changes through its development (started as a geolocalized procedurally generated 2d game, ended up a single player hand-crafted 3d game). Very early on we didn't have a PC version, and Nathan wrote a UI system initially aimed to be used on the touch panel. It was a typical OOP retained-mode GUI library design, and although I was a bit skeptical of that direction due to my early enthusiasm with the IMGUI paradigm, it did the job and we had a million other things to do with the game.

Fast forward December 2012: the tooling UI system is now used on a full-featured PC based tool. It did the job, but became a hard to maintain OOP+template monster requiring a dedicated person on the deck. At the same time our game is largely growing in scope and complexity, and I'm finding it difficult to add the debug tools I want to add. It is Christmas 2012, I am a bit bored and decided to write a new UI toolkit to be able to add debug tools. mkdir imgui/.

This is the time where all the foundations of existing Dear ImGui were laid out. I started populating the game with tools: minimap, property viewer, object browsers etc. By the time the game was released in November 2013, the game got a full-on suite of small tools helping programmers, level designers and QA do their job a little better (screenshots of some Tearaway tools).

tearaway-tool Early dev tools for Tearaway (PS Vita)

I moved on to start working on an early iteration of Dreams, and immediately port the imgui library to this new engine (both games used different custom engines). I don't recall precise details there, but initial code was calling directly into inputs, rendering, fonts components and other helpers of the Tearaway engine, and I have to rewrite all that glue for the Dreams engine. I believe at the time I duplicated the library and made engine-specific modifications in place, without initially attempting to abstract them as it was too much work. imgui somehow grows in in-house popularity.

Early summer 2014, I took the decision to leave Media Molecule soon. The very lovable Alex knows I am attached to this little bit of code, and kindly offers for the company to hand me over the rights to it, if I could find a way to extract it and remove engine and platform specific code.

By then it was a non-portable, custom-engine specific library. Heck, two libraries, since I forked and modified it between Tearaway and Dreams. What a mess. In my spare time I take the remaining month to start figuring out how the library could be redesigned to be engine-agnostic, so that the two projects could use the same library, and then more projects. Anton, Stefan, Matt are early testers and help with their feedback. Toward reaching that "reusable" design (a non-trivial feat in C++ graphics programming land) I converge toward the ImGuiIO, ImDrawList, ImDrawData structures as known today and implement examples using varying renderers. After many iterations, on August 11, 2014, I pushed imgui v1.00 on github.

I didn't really understand how to use git.

2.4. PUBLISHING (DEAR) IMGUI

The library gets noticed a little bit and gains traction. Surprisingly I can tell something was done right: only a few days after publishing v1.0, some people already had it successfully integrated into their project (again: trivial in many programming ecosystems, but not trivial in C/C++ graphics programming ecosystem, which was sort of even worse at the time).

I called the repository "imgui" because I didn't have any concrete plan for this project to take off. My primary hope was to reuse that code for myself. It's like working on a compiler and calling it "compiler".

I renamed it to "dear imgui" (about 15 months later) because "imgui" has been hogging up the whole acronym. I am sorry for the confusion caused even today.

Other people started using the library, posting requests and bug reports on GitHub. I spent an ever increasing amount of time on it. Evenings, weekends. In November 2014 I decided to open a Patreon to justify spending extra time on this.

I moved to central London and started contracting. I got spread out too thin: two contracting gigs, trying to make my own game, and an urge to work on Dear ImGui. One of the contracting gigs involved VR, I am not good at 3D programming and I got headaches. My contribution was quite a failure and I was embarrassed enough that I didn’t actually fully bill them for my time. The other gig was lacking tooling: I added Dear ImGui to the game; everyone got very enthusiastic about it and went on creating many tools. First large game outside of Media Molecule using the library!

On the side I was prototyping a game and searching for a publisher. End of November 2015, I started a company Lizardcube with Ben Fiquet to work on Wonder Boy: The Dragon's Trap. The game used Dear ImGui as its main tooling system, which gave me ample opportunities to keep working on the library.

TheDragonsTrap

The Dragon's Trap released in April 2017, following many months of rather intense work, pulling strings everywhere, handling simultaneous releases on 3 regions x 3 platforms, doing press tours and community management. The game was a success. But by release day I was already a bit of a burnt-out zombie... And then: patches, endless PC port, new SKUs, physical releases, more community management... it dragged on until October 2017 and I got truly exhausted.

Ben wanted to make another game. I was not sure I had the energy to make another game.

2.5. FOCUSED AND FUNDED ONWARD!

Around that time in Q3 2017, I received an email from Marco and Patrick from Blizzard. They've been using and toying with Dear ImGui and have a positive outlook on the potential of the library. At this point the version was v1.50. They were interested in funding improvements in order for it to be suitable for their new project. I visited them a few times.

Long story short: Blizzard ends up funding a good portion of my work Dear ImGui until 2023. Large chunks of work such as docking, multi-viewports, multi-select were initially driven by their needs. I mostly work with Patrick and then Joe, and their needs generally align well with where I want to take Dear ImGui.

Over time I also got many more funding contributions both from individuals and studios.

Since Q4 2017, my principal activity has been to work on Dear ImGui. This is the end of this “early days timeline”. I am not sure how to meaningfully describe the work done since 2017 as a timeline, but many later sections will refer to it.

ocornut commented 3 months ago

3. WHAT WENT RIGHT

3.1. INCREASED ADOPTION

Undoubtedly, the amount of people and teams using Dear ImGui have been growing. I would guess that perhaps ~50% of both small and AAA games built using custom in-house engines are using Dear ImGui in some capacity (e.g. Assassin's Creed, Clash of Clans, GTA 6, Marvel's Spider-Man, Zelda: Tears of the Kingdom etc.). I am seeing increasing adoption in large teams using Unreal Engine as well (unfortunately no official backends for UE, many backends and a rather fragmented situation).

Many in-house toy engines, research projects are using Dear ImGui. Many game/programming students writing their first engine are using Dear ImGui.

I am also seeing increased adoption outside of the game industry: people working on 3d, animation, AI, health, finance, cars, etc.

I believe when we finally tackle some of the most wanted features, the number of users may grow significantly higher.

3.2. TRUST / CONSISTENCY / LONG-TERM MAINTENANCE / NURTURING A CULTURE OF SUPPORT

Projects often live and die by their maintenance past the initial release. Following the initial v1.0 drop, the project could have gone nowhere. There are millions of published projects that don't get updated and gather dust. I choose to listen and care about people's needs, to create positive contribution loops. This is what some of my internal documentation says:

I am going miles to avoid unnecessary breakage, and simplify and document necessary breakage. Every major change comes with clever tricks to reduce negative impact on users.

The aim is to preserve and grow trust over time. In spite of its many historical quirks, one of Dear ImGui's best qualities as of today, is that it tends to be generally trustable.

3.3. API EASE OF USE

Another of Dear ImGui's qualities is obviously its API. The readme says that we aim to:

"Minimize state synchronization." "Minimize state storage on the user side." "Minimize setup and maintenance." "Easy to use to create dynamic UIs which are the reflection of a dynamic data set."

It's easy to overlook some of the work that goes into designing new features and APIs using a single-pass IMGUI that has little knowledge of what came before and what will come after. I tend to iterate and agonize for days over ways to simplify usage, select best defaults, name things, make code less complex for the users or for me. Some things have been rewritten a dozen times.

Publishing Feature X often requires design/proof of concept for Features X,Y,Z, etc. so I would have enough confidence that the API and names for Feature X will play along well with the API and names for future features. So I generally need extra visibility ahead, hence the 200+ private branches: they are often R&D for future things.

When designing things I try to be considerate for 5 categories/properties:

The "one-line/basic" poster child users:

The "advanced/polishing" users:

The inexperienced users:

The non-C++ users:

The long term users:

Every decision has to be considerate of those different cases.

3.4. LISTENING, HELPING, EAVESDROPPING

I tend to care about people's needs and try to listen to everyone. Some of the things I do:

3.5. RUNTIME PERFORMANCE

Dear ImGui needs to be as performant as it can.

General purpose heap allocations can be costly:

CPU/RAM/cache friendly:

General note about caching:

Optimizing debug builds:

3.6. LACK OF A BUILD SYSTEM IS A FEATURE

Encouraging people to build the library themselves had some valuable properties:

( Some cons however:

3.7. CATCHING USER MISTAKES

The library is littered with descriptive asserts and error checks. As a way to counter the amount of support requests, I am building a library that aims to need as little support as possible.

One of the directions I aim to go is to improve error recovery to facilitate cases where people are writing live code (C++ or other languages). There are already internal functions to facilitate recovering from certain error states.

It's however important to note that I always consider if those have an impact on performances. Some checks are altered or moved in strategic locations to reduce their impact accordingly.

3.8. IMGUI DEMO vs TRADITIONAL DOCUMENTATION

In the absence of a more typical form of documentation, the Dear ImGui Demo has been one of its best feature:

I am not against the idea of eventually writing a traditional documentation! However:

In addition, Dear ImGui has so many flags and features that the result of some unusual combinations may be undefined, or at least not explicitly stated. I am myself discovering creative uses from users that I didn't expect. Writing exhaustive documentation would increase pressure toward expliciting more things, which would in turn require me to dig into many more corner cases. Great? But I don't have infinite resources. And it seems better at this point to leave the corner cases explored and discussed empirically, on an actual per-need basis, rather than methodically. I envision that in a few years, given more human resources, we may invest more time into documentation.

3.9. BACKENDS

They are the main gateway to Dear ImGui. The software is appreciated because "it just works","everywhere" and it is partly due to the existence of backends.

For many many users they are a gateway to get stuff done: Research projects, experiments, home engines, student projects. Their existence creates tangible value for thousands of projects. Their existence facilitates the growth and education of many programmers, therefore indirectly serving the whole game/tech industry, even if a little.

On the other end, backends are also the bane of my existence (read the next section...).

3.10. CONTINUOUS INTEGRATION

We are running continuous integration for many backends, compiler and OS combinations, with aggressive warnings enabled. As we encourage people to compile Dear ImGui themselves, it also means that we are constantly catching up with whichever new zealous fangled warning gets introduced by a new compiler or C++ standard version (and the C++ standard committee seems to be aggressively making libraries maintainer lives a misery, IMHO, as it gets more and more difficult to create code that works across all C++ versions without something complaining).

3.11. TEST ENGINE AND TEST SUITE

In 2018 while working on Docking and other features of increasing complexity, I realized that I needed ways to:

The Dear ImGui Test Engine has been made public in late 2022 and is being used by a dozen teams (that I know of) to test their own Dear ImGui based software, in addition to it being used to test Dear ImGui itself.

https://user-images.githubusercontent.com/8225057/182409619-cd3bf990-b383-4a6c-a6ba-c5afe7557d6c.mp4

(Running Dear ImGui Test Suite, in Fast Mode, with full rendering enabled)

Embracing regression tests have been an enormous time-saver. Anytime a feature feels a little unwieldy to reason about, adding new tests has been a huge win. In recent years many issues reported by users lead to a bug fix + a regression test. Tests help detect changes to both the explicit and implicit contracts.

Not sure what a given piece of code is for? Modify/comment it and run the tests: you usually immediately find what side-effects this line may have. This is an incredibly useful property and accessible to all potential contributors and hackers.

Test Engine interacts mostly from the point of view of an end-user, by injecting mouse/keyboard/gamepad inputs into Dear ImGui's IO. It means it tries to "find its way" toward accomplishing an action by knowing how Dear ImGui works. Opening an item may mean CTRL+Tabbing into a given window, moving things out of the way, scrolling to locate the item, querying its open status, etc. It is de-facto a versatile automation system.

My hope is that in the upcoming years:

3.12. A WEB OF SEARCHABLE, PERSISTENT INTERLINKED INFORMATION + NEAT COMMIT HISTORY

All GitHub issues are carefully labeled and cross-linked to increase information discovery. Today GitHub has about 8000 issues/pr (with some repeated/overlapping issues obviously). Every time an issue is fixed or a feature added, I try to refer to ALL issues relating to it, including closed/duplicate ones.

Large commits doing many different things are avoided. Each commit tries to do one thing. This facilitates reviewing commits and bisecting issues. Commits are frequently including the Git Hash or other commits they are amending. Branches are rebased over master to create a flat history (with the exception of, ahem, docking). Maintaining a neat commit history also makes using Git Blame very useful: for any given line I can usually browse its history when I need to understand the context or when/why it was added.

More focus has been put into the Wiki in recent years It actually became quite useful!

3.13. FUN COMMUNITY EVENTS

The Gallery Threads have always been a fun way for people to showcase their work using Dear ImGui.

In November 2020 we also ran an informal ImDrawList coding party. In this 10 days event people were encouraged to create effects using the ImDrawList API, with a constraint of 1024 bytes of source code:

#define V ImVec2
#define F float
void R(F&x,F&y,F r){F s=sin(r),c=cos(r),t=c*x-s*y;y=s*x+c*y;x=t;}
F c,e,f,g,l,r,x,y,z;
int i,j,k,u,v,K=24,J=48;
F L(F a){l*=l>0;return sqrt(1-exp(-a*(l+.1)-l*l*l));}
void T(F u){R(x,z,c+6.28*u);}
V P(F t){t*=3.14/K;return V(sin(t),cos(t));}
void FX(ImDrawList*d,V a,V b,V S,ImVec4 I,F t){
V o[4],m=(a+b)/2;c=t/2;
k=sin(t*13)*24+24;j=-0xafefb0+k*0x101;d->AddRectFilledMultiColor(a,b,j,j+0x503010,j+0x4050,j+0x7040);
for(k=K;--k;){for(j=J;j--;){for(i=4;i--;){
u=j+(i%3>0);v=-(i/2);
V p=P(k+v);x=p.x;y=p.y;z=0;
T((F)u/J);e=x;f=y;z=S.y/(g=z+2.5);
o[i]=m+V(x,y)*z;}
V v1=P(k),v2=P(k-1);
x=v1.y-v2.y;y=v2.x-v1.x;z=0;
l=sqrt(x*x+y*y);x=x/l;y=y/l;T((j+.5)/J);
r=2*(x*e+y*f+z*g);
e-=r*x;f-=r*y;g-=r*z;
l=sqrt(e*e+f*f+g*g);
x=atan2(e,g);y=atan2(sqrt(e*e+g*g),f);
l=sin(x*5+sin(y*3+t))+sin(x*9+sin(y*5+t))+cos(y*4+sin(x*5+t));
l=l/4+.5;
I.x=l;I.y=l*.9*(.8+e/4);I.z=(.5-f/2)*l/2;I.w=1;
if(r>0)d->AddConvexPolyFilled(o,4,ImColor(I)),d->AddPolyline(o,4,0xff<<24,true,1);
}}}

(1022 bytes) Totally sane code courtesy of @pmalin. The full thread has many other cool stuff.

DiscoBallD

We should do more of these :)

3.14. GREAT THIRD-PARTY ECOSYSTEM

As featured in our Useful Extensions wiki page there is a striving community of extensions. The most commonly used is most certainly implot by @epezent:

implot

But there are many others popular ones! imgui-node-editor! ImGuizmo! netImgui!

I myself compile some of the most commonly used extensions to ensure they stay compatible with the latest version of the library, and sometimes submit patches accordingly.

Among other things, as mentioned we also have many bindings and backends, for a variety of languages, frameworks and engines. Also many articles and videos.

4. WHAT WENT WRONG

4.1. BEING A JANITOR + A COP

Tending a community with a growing number of requests (1000+ open issues/pr open as of today) is a marathon. Even though we improved our templates, guidelines, our FAQ and Wiki, inevitably a large portion of questions are people's own mistakes.

Combined with the fact that they are not providing the right information we need to help them. It inevitably ends up frustrating, making me sound occasionally grumpy and rude, which itself is demoralizing. :(

-> I will need to learn to take a little more distance with the community. -> I keep reminding myself that with every duplicate question/answer we tend to make a step toward having the information more readily findable.

4.2. ANSWERING TOO FAST

For years I have been too reactive with answering questions. While it is short-term nice for the person having a problem, I believe this hindered the community from growing. Me answering too many things too fast didn't leave space for other people to engage in the community.

Nowadays I force myself to not answer every question in order to leave room for others to engage. For a few years we have had an increase in regular contributors (@PathogenDavid, @GamingMinds-DanielC, @thedmd, @cfillion and many more. Thank you!!)

-> Again, I will need to learn to take a little more distance with the community.

4.3. DROWNING IN THE ATTENTION ECONOMY

Requests coming every day, at every hour. Moreover, I am providing private support to e.g. companies in the West coast while being in France, different time zones, meaning I'm often asked questions when it should be the end of my work day.

There are just too many requests to catch up with in a timely manner. I have accepted that some things are going to take a while. If you are a user of Dear ImGui, please accept it: I have limited resources and I don't want to compromise software quality.

One issue with this is that small issues have been taking the lead over big ones.

-> I will need to set stronger priorities and spend less time pulling out fires everywhere and catering to everyone's needs.

4.4. NOT ACCEPTING MORE CONTRIBUTIONS

I genuinely wish I could accept more major contributions at a faster pace, but the truth is that most are incomplete or have issues.

Pull-requests are well-appreciated contributions, and almost always point the finger at a real need. But it doesn't mean the suggested solution is the right one or is efficient enough. I suspect that for a majority of them (not all), I spend more time reviewing and fixing the PR than the time it took the author to write the initial patch. They also sometimes open up larger areas of work which I am just not ready to tackle.

I am certainly a control freak here. Some projects may accept contributions a little more easily. But between trying to guarantee performances and API future-proofness, dealing with overall system complexity and the large variety of use cases, etc.. I can't really see a path where it would be easier to accept more contributions and faster. Other than requesting people to spend more time on them and get more reviewing help. The Test Suite was designed as a way to help people making contributions, but it hasn't yet been widely adopted by users (please try it!).

-> I don't believe there is a good solution to this problem: many contributors are naturally "passer-by". They have an issue and want to solve it as quickly as possible and may not see conflicting use cases. It would not be reasonable to expect them to understand and fulfill every ins and outs of this project. -> But I can spend more time reviewing, merging or encouraging people making good contributions in the hope they will come back.

I haven't been able to bring too many people to help. I should/could do better here as well.

-> But generally, increased contributions from people answering GitHub has been a lifesaver and breath of fresh air for me.

4.5. PERCEPTION OF PROJECT STAGNATING, WHERE ARE THE NEW COOL STUFF?

Dear ImGui has made great strides of progress between 2017 and 2021. I suspect that nowadays some people are perceiving the library as rather stable but also a little stagnant in terms of big features. People have accepted that the library is here, they may be a little less excited about new updates.

In fact, thousands of great changes and additions have been made and are still being made. Between 1.90.0 and 1.91.0 the Changelog spans 800 lines.

But it is true that some "surface" elements and commonly requested tasks haven't been making enough progress: styling, fonts/text system, docking among other things, which may contribute to that perception.

Being drowned in small tasks I delayed some big areas of work from making progress and maybe I should not have done so.

-> Onward I will resume work on big areas that have been stagnant (next chapter!).

4.6. GENERAL BURNOUT, LACK OF FOCUS, ADHD

I logged most of my working hours, and noticed a large drop of focused working hours between 2018 and 2024. Which is a sign that I am still partially in a state of slow burnout.

It's also a side effect of having to deal with the complexity of an existing codebase that people are relying on. I noticed that when I work on new features it is easier for me to focus for many consecutive hours. Whereas in a typical working day having to meticulously care about changing existing code or switching context, I often end up tired earlier.

I have a strong Inattentive+Impulsive ADHD, which among other things tends to make me switch tasks and solve new problems immediately instead of accepting to solve them later.

I run other personal projects, I run a company and I am trying to make this economically viable: things other than coding have also been taking too much time and energy.

Fun fact (and this is not new): I have never been able to read and understand long chunks of text or spoken words. I think I've read 2 programming books in my life (one in 1999, one around 2002). I've almost never been able to read a technical paper. I get by reading blogs, talks, small things here and there. Heck, I have difficulty chewing on anything that's not very small. I have difficulty remembering things at all. This is why I always divide and conquer; this is why I split commits; this is why I cannot review 1000+ lines PR and need contributions to be bite-sized and carefully isolated from each other; this is why I tend to be meticulously organized in some areas. Please bear with me :)

-> I have already largely improved my work-life balance in recent years. -> I will need to do better and counter the ADHD more methodically, to keep focused on important tasks. -> This year for the first time I have repeatedly met with specialists and went through many tests to diagnose my particular flavor of ADHD, and perhaps find ways to manage it better. -> Tackling new, bigger tasks will contribute to my own motivation.

4.7. UNPLANNED CAREER CHANGE

Dear ImGui took me by surprise. I stopped making games! I left a successful indie studio that I co-funded to make the things that I wanted to make.

-> I've accepted this for now. Perhaps I will make another game later but now I feel more useful working on Dear ImGui.

4.8. MAINTAINING BACKENDS 😭

In theory backends should be simple and short. v1.0 didn't even ship with backends, they were so simple they were deemed "examples" back then. In practice: a continuous maintenance nightmare, because people use those backends in endless situations. Because computers, platforms and graphics systems are complex and are moving targets, the backends are constant attention hogs.

The attention and maintenance costs of backends has been very disproportionate to e.g. their code size.

I am also not as familiar with some of the technologies used by backends, e.g. Vulkan, DX12, WGPU, Emscripten, OSX peculiarities are not things I am well versed at. I try to learn on the spot, but I am often relying on contributions. Heck some of them I can’t build myself.

Working on backends is generally useful, but it always comes with the feeling that I am not working on improving the main library.

-> Deprioritize them a little bit. -> Rely more on contributors to help.

4.9. LACK OF VISIBILITY OF SOME FEATURES

Dear ImGui has so many features that people don’t quite know everything. I try to leave hints and references in many places, but helping people discover features in on-going battle.

The list goes on, but I recommend if you can to try peeking at Release Notes on GitHub from time to time!

4.10. DISCORD AND FRAGMENTED COMMUNITIES

A few years ago, I caved to recurrent requests to open a Discord. My conclusion to the Discord experiment was that:

I thought it was detrimental to information quality, to the community and to the software itself. In early 2021, I decided to close the Discord server (1900+ users), fully embracing GitHub issues as a central point to gather and search for information.

I believe what people want out of a system like Discord is to be allowed to ask questions with less effort, but in my experience we always end up requiring extra information and doing unnecessary back and forth.

I also tried using a Discourse forum, and taking advantage of GitHub Discussions. None of them seemed to provide value over discussing in a centralized location. My main and only issue with GitHub Issues is... the fact that the tab is called “Issues”. Some people may be discouraged to ask certain types of questions there.

ocornut commented 3 months ago

5. STRATEGY OF PACING GROWTH & CROWD CONTROL

This is perhaps one of the least obvious aspects of my long term vision toward Dear ImGui. I've hinted at it in comments here and there but I think it is important to write it down in a more visible location.

Dear ImGui already has many users and a continuous, overwhelming flow of support requests. I believe it has the potential to have x10, x100 the numbers of users in the future. This is a marathon. To preserve my own sanity and stamina, I need to pace the growth of its user base.

If we get x10 the amount of users tomorrow, would we benefit from x10 the amount of funding and be able to hire people? I am not sure. Even if we did, it's not like scaling engineer count is easy and comes without additional complexity.

Therefore, it is NOT to my advantage to attract too many users too fast. I prefer to work on core things at my pace. Catch up with technical debt, write better code. I prefer to first figure out how to better rely on the community to help.

This is partially why I have intentionally under prioritized features such as:

I must however say that I am NOT against those things. But I've come to understand how every feature requires more work than meets the eye, and I am not rushing into those. Some other features (such as full internationalization and proper accessibility support) have also been unfortunately under-prioritized due to a combination of trying to limit the user base AND keep the codebase simple.

About accessibility (*edit*: this was added a bit after the initial post) I do know that Dear ImGui unfortunately does not align with requirements of accessible software. It was designed as a technical/debug tooling software to be used as an overlay over 3d/graphics applications which themselves tends to have little to no accessibility features. It's not really my fault that people have started using it for desktop-ey applications. If you do use it for a tool please be mindful the tool won't be accessible to most screen readers (on the other hand, I can't comprehend why screen readers are not more relying on OCR?). People keep pushing Dear ImGui into new boundaries! I'm happy with that but please bear in mind we have limited resources to catch up with every requests and every needs. I'm obviously not against providing some form of accessibility or screen reader support but I am likely not equipped to do this work and the code design of the library may make it harder to find easy solutions. If solutions and quality patches materialize, of course.

Dear ImGui would NOT BE ABLE TO EXIST if it tried to solve every problems and use cases. It does not.

None of the technical issues are unsolvable, but Dear ImGui does well because it knows what it can do and what it cannot do. I think Dear ImGui will flourish better and grow older nicely if it keeps managing its scope of responsibility.

I will help people trying to push it further, but I intend to keep marketing Dear ImGui as a UI toolkit for low-level-ish programmers to make technical tools.

6. PRIORITIZING LARGE TASKS AGAIN!!!1

The general idea is that many arguably much-wanted and much-requested features have been under-prioritized in recent years, and not just because of the "Pacing Growth" strategy. One reason has been that each of those tasks require weeks if not months of deep focused work to make notable progress, and I have always been too taken by fixing things, putting out fires here and there, or dealing with requests from certain sponsors. Now that I am working toward reframing sponsoring and that multi-select is mostly out, I want to aim to take on bigger tasks.

Taking on bigger tasks will require me to more bluntly accept that I cannot provide daily timely support the same way I've been doing in past years.

In the upcoming years, I will aim to make those items the 10 priorities:

  1. Better font support.
  2. Better text functions.
  3. Better support for DPI scaling.
  4. Tackle some main Docking issues
  5. Rewriting Docking (v3)
  6. Rewriting Multi-Viewports (v2)
  7. Rewriting InputText (v2)
  8. Better styling (v2)
  9. Better layout helpers
  10. Better support for idle mechanisms.

I am not able to give a roadmap nor schedule, but suffice to say there are years worth of work to get everything done neat. I still need to carry on with maintenance and have many other things to do. If I can spend even 40-50% of my time on those features, we will make great progress.

6.1. BETTER FONT SUPPORT

BACKEND SUPPORT FOR TEXTURE UPDATE

To allow for dynamic fonts, we need a standardized, future-proof design for backends supporting texture updates. This includes partial rewrite of texture data, creation of new textures. Rewriting pixels of textures that are used as part of in-flight rendering needs special work.

Nothing rocket science, but it needs an API that will last for years because this is at the contact point between Dear ImGui and the user's engines.

One difficulty is to provide this feature in standard backends (e.g. dx12, vulkan, metal, dx11) in a way which can be used as a drop-in regardless of how the application/engine designed its rendering pipeline.

This will be the backbone for: dynamic fonts, dpi, baking shapes/symbols or custom texture data (e.g. past work on shadows was stuck for lack of this, though shadows are less important today w/ dark theme+viewports+docking).

MORE DYNAMIC FONTS

Built on top of backend support for texture updates: make font atlas finally dynamic. This will greatly facilitate the use of Asian languages, large icons, changing font size, zooming, etc.

While doing to refactor user-facing font api and internals:

I don't want to get into too many details here regarding actual glyph rendering technology. I don't think this is the actual crux of our problem to know how things are rendered, as long as they look good.

PACKING/BAKING NON-FONT DATA

6.2. BETTER TEXT FUNCTIONS

WHAT WE WON'T DO

It is unlikely that stock Dear ImGui is going to support right-to-left languages, bidirectional texts, text shaping, full internationalization, etc. We are forced to draw a line somewhere so Dear ImGui doesn't grow into a software I cannot maintain. But we will make reasonable efforts to make it possible for forks to do so.

6.3. BETTER SUPPORT FOR DPI SCALING

While they are ways to provide DPI/scaling support they are currently mostly left to user (primarily because there are varying solutions). We should aim to standardize this better.

The big difficulty is "multi-DPI" aka to support varying DPI scale across multiple viewports across multiple monitors simultaneously: I still don't have a solution for this that ticks all the boxes that I want to tick simultaneously (performance, etc) but will keep investigating.

This difficulty has created a situation where many more simpler situations haven't been solved out of the box. This has been a mistake on my part. We will focus on solving the 90% easier situations out of the box e.g.

6.4. TACKLING SOME OF THE MAIN DOCKING ISSUES

Before tackling the next step [6.5], I would have to have a pass at tackling some of the common problems.

Those two things above are trickier than most people realize, because they rely on designing ways to identify docking locations in the long term, after users have hidden, split, merged nodes, restarted the application many times etc.

WHY ISN'T DOCKING MERGED ALREADY ?

6.5. REWRITING DOCKING (v3)

Current version of docking is v2 (I have never released v1 publicly). It has too much complexity / technical debt / code smell for my taste.

Thankfully it's not an API heavy feature:

Will need to rely more on automation/testing. Been relying on it already to facilitate that transition, but ultimately a new version will need to be written alongside with more tests. I may need help.

6.6. REWRITING MULTI-VIEWPORTS (v2)

Current version is v1, too much complexity, tech debt etc. I think it is actually harder than Docking to make perfect, on all OS, WM, drivers, etc. It's an endless moving target. But a rewrite may be reasonably easier. There is not so much code. Most backend work may be reused, don't need rewrite, and ultimately core-lib viewport code amounts to not that much.

This will require me to spend more time using Mac and Linux systems. Argh again.

Also rely more on automation to test OS/WM dependent corner cases. We already have a "multi-viewports emulation" backend in Dear ImGui Test Engine, and need to further improve it. As we tackle more OSX/Linux related issues, the behavior of WM should be integrated into the mock-viewport backend.

6.7. REWRITING INPUTTEXT (v2)

InputText shows its age and has technical debt preventing easy fixes and improvements (50+ open issues, although some overlap)

Should be rewritten. Get rid of stb_textedit dependency, wchar buffers, transitional buffers.

General target is to be able to view/edit a multi-megabyte file without noticeable cost.

Some desirable features:

6.8. BETTER BETTER STYLING (v2)

Improve the general visual look and styling features.

We basically want Dear ImGui made user interfaces to look "great enough" by default, so its look isn't a problem or a talking point anymore. It'll naturally lead to exposing more configurable and complex data for visual configuration.

HOWEVER it is NOT a goal to aim for a 100% skinnable GUI system. That's just too complex to get right and optimal.

Pitfalls:

Likely:

It will be difficult to design/implement mostly because of the need to provide a decently smooth transition for existing codebases. If we have a cascading series of "Text Colors", then a legacy api such as PushStyleCol(ImGuiCol_Text, ...) can become ambiguous or problematic (it would be "legacy-correct" that it overrides everything in the hierarchy, but that would also make it more difficult to have a continuous/smooth transition between old style and new style).

Some creative/pragmatic paths will need to be designed to facilitate a healthy transition.

Easier font resize and color/markup systems will also be key elements to improve look and feel aside of “Styling v2”.

6.9. BETTER LAYOUT HELPERS

A bunch of ideas have been on hold for fear of "breaking too much & too often" I have accumulated a bunch of requests & notes, so hopefully we can tackle things in a batch.

Some key low-level blockers:

What I think are pragmatic mid-term improvements given codebase and user code history:

Things that have been hairy or messy:

R&D (longer term): Opt-in local multi-pass

R&D (longer term): Proof of concept of a layout editor:

6.10. BETTER SUPPORT FOR IDLE MECHANISMS

Implement/demonstrate officially supported idioms to develop apps going full idle (e.g. desktop-ey apps) without applications crafting their own solution.

Deep down, one of my issues with this was that it will attract/increase the population of users for non-game industries and therefore increase support requests :P

Non-obvious extra mile features:

6.X. AND MORE

I obviously have hundreds of other ideas, things I want to do or finish. But the 10 above are the big things I most wanted to elaborate on today.

ocornut commented 3 months ago

7. FUNDING 💰

Nowadays I am generally getting enough to keep working on Dear ImGui! But consider:

The software is still largely underfunded:

It is a lots of work to get funding. Chasing sponsors and funding takes constant time and energy:

Chasing sponsors and funding is a roller-coaster, it gets emotionally taxing.

Help doesn't always come from the bigger players:

I have to provide private support:

And that's WITH being lucky:

Coming to terms with reality:

Some pattern I noticed over the years:

Pivoting to sell Test Engine licenses:

Until Dear ImGui is self-sufficient, this is the ideal sponsor:

8. HOW TO HELP

DEVELOPMENT & COMMUNITY https://github.com/ocornut/imgui/issues

FUNDING

DearImGui-Logo-1000x349 (painting by albane kim)

THAT'S ALL FOLKS!

I can't really tell if writing this is going to be helpful. It's probably a little unstructured like my mind is :)

Thanks for reading! Thanks for your continued support. Thank you to all supporters, funders, developers, commenters, users, who are making Dear ImGui alive. 🙏 Thanks to @thedmd, @jlaumon, @shironekoben, @rokups, @tdev., for proof-reading and commenting on this post.

On so many more productive and fun years! I will keep trying keep Dear ImGui sane, friendly, efficient, relevant.

🙏 Please be kind to not use this thread to request or discuss features! It would be unmanageable. You can search or open new issues if needed! But feel free to reply with your impressions about this post or about Dear ImGui in general! Thanks!

tdev commented 3 months ago

@ocornut thanks so much for the amazing work over the years - on to the next 10 years!

ggerganov commented 3 months ago

@ocornut Thank you and the community for creating Dear ImGui! Very interesting read. Your work is an inspiration ❤️

pozemka commented 3 months ago

@ocornut Thank you for such amazing library. You work literally sparked in me joy to program again. Wish you all the best! ❤️

jlaumon commented 3 months ago

Here's to the next 10! 🍻

immortalx74 commented 3 months ago

Thanks for sharing your thoughts, it was a very nice read. And quite the opposite of "unstructured"! It's amazing that a whole industry lead by multi million dollar companies couldn't figure out how to do a proper UI framework that can be used everywhere, and one guy alone did it and successfully maintains it for a decade.

Peter0x44 commented 3 months ago

I found this really insightful and informative. There's a lot contained here that wasn't obvious or expected to me.

alexlnkp commented 3 months ago

Thank You for the work You've done. All of us are extremely thankful for every single minute You and all of the contributors have spent working on this amazing library, while also providing one of the best user support I've ever seen, even across FOSS.

But I'm wondering... what does that mean?

If you are a victim of some trillion-dollar company offering you $250, please politely refuse it (cough) and try to engage in obtaining better from them (or nothing).

Spaceghost commented 3 months ago

imgui was part of my spiritual journey through gamedev, it was and remains present in every substantial long-running game community's toolkit. Thank you for making gaming the most interesting place to write and share code.

~Spaceghost

JeffM2501 commented 3 months ago

Very good post, good info. I miss the work we did with you at Blizzard :(

LuckyIntel commented 3 months ago

Thanks for this amazing library!Even though I suck at programming, this library somehow manages to keep creating GUI process both easy and simple that even I can understand.Happy birthday Dear ImGui!

aras-p commented 3 months ago

That's a great write-up, thanks Omar! Besides all the "personal story" things, a lot of what you write about (what is important, how to approach API design, how to interact with users, etc.) is generally a great wisdom in general, even outside of dear imgui.

CedricGuillemet commented 3 months ago

I can't believe it's already been 10years. Dear imgui changed my entire way of working, designing and delivering SW. Thank you so much for that. You are doing an amazing job. Long life to dear imgui!!!

raysan5 commented 3 months ago

Great post! Really inspiring and educational! I can see myself reflected in many of the points! Taking some valuable lessons from it! Thanks and congratulations for your amazing work!

photex commented 3 months ago

Congrats on 10 years! Thank you for your incredible efforts!

gccore commented 3 months ago

Great Great post; Thanks! I learned a lot from it.

dsieger commented 3 months ago

Thanks @ocornut for creating and maintaining this excellent library. Great post and thanks for sharing your insights and perspectives here. Looking forward for the next 10 years!

questor commented 3 months ago

I'm really bad at writing editors with the classical tools (mfc, wxwidgets, qt) and really struggled with my (private) projects when I needed an editor, but with imgui I'm really able easily to write editors and debugging tools without much thinking! a big THANK YOU for such a great library and the careful thoughts how to improve and change over the years! And as a user of the library you really recognize that you really think about the api unlike most others... on to the next years and keep coding!

olinorwell commented 3 months ago

@ocornut I was planning to simply congratulate you on 10 years of the project, but instead I want to also thank you for this post. It's very well written and will give strong motivation to all of us with long term projects to do something similar. Great work all round. I spread the word about Dear ImGui as much as I can and I'm using it in several projects. Thanks from Spain.

pthom commented 3 months ago

Hi Omar, many thanks for those words of wisdom, and congrats for your long lasting efforts on developing and maintaining this library, which also changed a lot the way I do research and software development.

tpecholt commented 3 months ago

Hi Omar, thanks for developing such a great library as ImGui is. I like the ease of development which it provides. It's great to see its adoption is growing.

Can I react to few points here?

1. UI Editors

Several people have written competent "UI editors" for Dear ImGui (link). I personally think they are all severely flawed because they are limited to be useful as a first pass helper. They don't cater for data/action bindings which is the crux of the problem when working on UI, and they don't facilitate subsequent iterations after the UI has really been coded.

I am the author of one of such UI editor - ImRad. ImRad was designed from the beginning to support data/action binding and allows subsequent iterations (it generates and imports generated c++ code). These are indeed important features to have. So perhaps the statement above is not entirely accurate.

Could I ask you to update the image in the UI editors section as well? This picture is from an early stage of development and the current version looks different.

2. Better Layout Helpers ImRad implements a simple but universal layout helper on top of ImGui. It allows to stretch any widget in horizontal or vertical direction. That includes a spacer widget to achieve alignment (see the last picture from the wiki page) . After user clicks the stretch button for size_x / y widget property the behavior can already be tested in the designer. I am not saying it's the best and only approach but perhaps you could take it as an inspiration. I noticed a separate branch for spring alignment helpers but that's not enough to have. Not only springs, all widgets need to be stretchable.

3. API Suggestion This was probably suggested in the past already but I wonder why not to introduce StringView in the ImGui APIs. It seems rather straightforward and I see several benefits:

mamoniem commented 3 months ago

Wow, time flies! Great job & amazing read, specially the personal aspect!

Riztazz commented 3 months ago

Congratulations :)

@tpecholt https://github.com/ocornut/imgui/tree/features/string_view

ocornut commented 3 months ago

Thank you for your comments! I have made a few minor amends here and there to the post.

@alexlnkp:

But I'm wondering... what does that mean? "If you are a victim of some trillion-dollar company offering you $250, please politely refuse it and try to engage in obtaining better from them (or nothing).

I mean that open-source software relying on sponsoring should not accept very tiny amounts from very large companies. Accepting it allows them to keep low-balling developers. Google offering $250 to open-source developers while making blog posts about it is a little offensive, it's essentially cheap ethics-washing. Consider that amount correspond to one or two hours of work from engineers working in their Bay Area offices. It would actually be a tiny bit more acceptable if they kept quiet about it, but of course the point of that comment was to say that if those companies want to contribute to e.g. raylib, they should contribute larger amounts. (I need to clarify that I personally did receive meaningful funding from Google several years ago, through knocking on other doors, and I am very thankful for it. I am merely disparaging certain cheap ethics-washing initiative which I suspect are actually designed to please their own employees at minimum cost).

@tpecholt

ImRad was designed from the beginning to support data/action binding and allows subsequent iterations (it generates and imports generated c++ code). These are indeed important features to have. So perhaps the statement above is not entirely accurate.

I apologize for overlooking that and adjusted those sentences to reflect the different capabilities of some solutions like ImRAD. I will investigate your tool and Wiki with greater care. I also apologize that this section seemed to bluntly ditch on a whole area of tools. I am genuinely interested in seeing how with greater collaboration from Dear ImGui core (e.g. that proof of concept I mentioned, which would requires a few mods in the core which I am aiming to make anyhow), a tool like yours could cover an even wider scope of use case. I updated the screenshot and added another tool (https://fellowimgui.dev/). On your third point please refer to my "Please be kind to not use this thread to request or discuss features!" or this is going to be unmanageable here. We have an active and updated string_view branch, see #3038. Your feedback on it can be useful.

Vin789 commented 3 months ago

Thx you @ocornut for Dear ImGui and all the hard work.

I have been pushing ImGui at all the video game companies I have worked for, big or small. I have probably crafted more than 100 different debuggers with it for a myriad of features.

I could not imagine working without it, equally in professional and personal projects.

For me, Dear ImGui is a mandatory debug tool for any video game developer.

Merci encore pour tout ce travail et cet exceptionnel outil !

Ajblast commented 3 months ago

Thanks for everything that you have done for this library @ocornut. This post was so informative and was a very good read about the history of Dear ImGui. Thanks again for everything and this amazing library.

It was great working with you at Blizzard.

peterigz commented 3 months ago

Very interesting read, thanks for taking the time to put that together! I've been using Dear ImGui for about 3+ years now and will very likely continue for many more years. And the software I'm working on now has 206 tests and counting and continuously finds bugs where I broke things, so extra thankful for the test engine too! 👍

tenyuhuang commented 3 months ago

Thank you making this awesome piece of software, and this has been a very interesting and insightful read. I've used and benefitted from ImGUI a huge ton, but I've never knew you've worked on so many amazing projects in prior (including a few of my favorite games). Looking forward to the next decade, and more!

GamingMinds-DanielC commented 3 months ago

Long read indeed, but very interesting. Thank you for all the effort you put in.

0x3C50 commented 3 months ago

I've been using the library for a while now, and it's just been so different from everything else I've tried (in the good way). Making simple GUIs for developers to use is so incredibly easy, and they look good, feel good at the same time. I really think this project might have become an actual cornerstone in the graphical development industry, just based on how simple it is to make efficient and good looking developer tools. Thank you for all your work!

malloc2k commented 2 months ago

Wow. This was a crazy long read but absolutely worth it, also Ocornut i wanted to ask you if the fact that ImGui is used nearly in every CSGO or CS2 cheat or similar games cheats ever bothered you. Thanks :P

EddieEldridge commented 2 months ago

Wow. This was a crazy long read but absolutely worth it, also Ocornut i wanted to ask you if the fact that ImGui is used nearly in every CSGO or CS2 cheat or similar games cheats ever bothered you. Thanks :P

They made a post about that here: https://github.com/ocornut/imgui/issues/1586

malloc2k commented 2 months ago

Wow. This was a crazy long read but absolutely worth it, also Ocornut i wanted to ask you if the fact that ImGui is used nearly in every CSGO or CS2 cheat or similar games cheats ever bothered you. Thanks :P

They made a post about that here: #1586

Thanks so much

bryanedds commented 2 months ago

ImGui is the KEY factor that enables our game editor's user-extensibility far beyond what any retained gui can provide in practice. To us, the extensibility built into the ImGui paradigm was and continues to be the primary value proposition. And Dear ImGui specifically is the reason why we didn't even have to consider writing an ImGui ourselves! There's no sufficient way to emphasize how Dear ImGui and its lineage makes straight-forward the otherwise impractical!

simonvanbernem commented 2 months ago

Your work along with casey's was the reason I decided to create an imgui for my masters thesis. This library showed me that UIs don't have to suck and for that I might be even more thankfull than the tremendous value I got from it.

Just signed up for 5$/month. Once my unreleased game gets super successfull and I become a millionaire (because that's how gamedev inevitably works out 😂), I'll definitely up the support!

Thank you for creating this ❤

spiriapbergeron commented 2 months ago

Bonjour Omar,

(sorry this is a long post, but I think you might benefit from it)

Congratulations on your really great project. I've read your post and couldn't help to think: "I would like to help this guy look at his challenges from a different angle".

I apologize if this is a long reply/comment, or, if there's really nothing new here below. But, I am taking the time to write this, as perhaps you will find some elements of solutions to the "core non-tech problems" of developing Dear Imgui you have been experiencing for so long.

Your growth challenges (because that's what you are facing) are typical of what happens to successful small businesses that are founded by "technicians". By "technicians", I mean the generic term of someone doing the "technical work". Whether it is the baker doing amazing baguettes, or the programmer doing an amazing toolkit, the challenges tend to be similar when you are the "secret ingredient" to the success of the venture, and when "most of the help" you get from others (employees, foss contributors) often seems more like a hindrance than actual help, because "they aren't doing it the right way" or "aren't doing it the way you'd do it yourself". Because of that, it often feels like it's actually more work to review / integrate / adjust / rework / educate than it is to redo the actual work yourself, and eventually you come to the conclusion that having others do the work (as opposed to just you) is actually counter-productive to the well-being of your project (eg: takes all of your time, you have none left to do any actual work yourself, and it feels like you could go faster yourself). In fact, it often feels like since you're the only one who can correctly steer that ship while having to take care of everything (managing finances, finding funding, managing priorities, doing the work, having a life) things get overwhelming very fast, and could lead to burnout.

I'm guessing this resonates maybe at least little bit -- since you've made some allusions to these issues in the above series of posts.

Please do realize that you yourself are 3 different kinds people to Dear Imgui:

(1) You are the "Entrepreneur"; the person with the dream, the vision of everything it is now, of everything it will be. As the "dreamer" -- your goals are big, you're impatient to see your vision be realized, and if you could, you'd have everything, right now. The entrepreneur is also the "businessman": needing to finding partners, funding, making sure the entity is healthy and doesn't run out of money, and sets short/mid-term "business" goals (* this topic could be the subject of a whole different discussion).

(2) You are also the "Manager"; the guy tempering the goals and ambitions of the "Entrepreneur" with what is realistic and what must be shipped in the short term. As the manager you are the link between the entrepreneur and technician -- to keep everyone aligned with the roadmap, and to come up with a plan to achieve the most pressing business objectives set by the entrepreneur. The manager, not at all a dreamer, must be "rigid" to be successful. He is the anti-dreamer (keep things realistic) and anti-techie-adhd who wants to have fun. The manager is the boring guy who must do everything to stick to "the schedule": push back against "the entrepreneur" for wanting to go into different directions, and push back against "the technician" for wanting to go off on tangents to try new things. Being the manager is the most uncomfortable position; you're everyone's adversary, and it feels like your work is akin to trying to herd cats and align them to shifting priorities. ugh!

(3) Finally you are also the "Technician"; the guy doing the programming. The guy wanting to try new things, new approaches, the guy implementing things that are "wow-so-cool!". As "Omar", I'm guessing this is where you spend most of your time, or at least want to, because that's where you're most comfortable; it's what you love doing, it's the reason your project is a success in the first place; and besides, this fits well with your ADHD personality and fulfills your need for creativity just fine. And while you understand the necessity of the manager (but dislike the pressure and the constraints and the rigidity that comes with this role) and sometimes think the entrepreneur is straight out of his gourd if he thinks he can accomplish all of the goals in the short term with the current team, this is also what keeps things exciting.

Does this ring a bell? I'm willing to bet a hot dog that it kinda does. Did you realize you were wearing these hats, and that all 3 people had competing interests, and that if you wear all 3 hats this way, that's why it may feel a little schizophrenic? Because indeed, all 3 hats actually require different personalities, and it's extremely difficult to always be all 3 at the same time. I'm sure you did, at least intuitively, because again, you indirectly allude to this in your above posts.

And I'm sure it feels like an impossible situation to fix.

When faced with this situation, technical entrepreneurs have 2 choices: (A) build ramparts around their little kingdoms, block external noise, and focus on what feels like the "most important", eg: the technical work.... Or... (B) Take a step back, and aim to solve this paradox once and for all, in order to regain some form of sanity and balance.

To me it feels like you've chosen (A), but I invite you to take a 2nd look at option (B).

Because right now you are both the locomotive, and at the same time its strongest brakes.

But how do you fix this?

Isn't that the biggest question?

Perhaps I can help -- maybe, perhaps, offer some thoughts here? Or maybe it'll help you progress in your thinking.

(Step 1) : First, I would like to speak to the person wearing the entrepreneur hat for a moment, and invite you to rethink some of your licensing terms. Your largest clientele by far seems to be game studios, so I'd start by making game studios pay for a work product that is absolutely critical to them. It's not fair that AAA studios insult you with 250$-1200$ donations in exchange for a perpetual license. You know what, just being offered this kind of deal would be just the thing that makes me rethink the licensing terms for Dear Imgui. At the same time, I understand the need to keep it free for the community, smaller entities, and out-of-your-core-clientele projects, even commercial projects.

Maybe think about something along the lines of the tiered Unity3D licensing terms? Eg: paid license only for large-ish game projects, but keep it free for everyone else? (free for community, education, scientific, and any commercial-but-non-game projects?)

https://support.unity.com/hc/en-us/articles/28114350573460-Which-Unity-Editor-license-should-I-use-purchase

In fact, I'd make this relicensing apply to any game development project that is started after the date of the new licensing terms, regardless of the version of the Dear Imgui used, and even if "Imgui" is already "built-in" some engines that are being repurposed/improved for new games. I think this would only be fair to you.

In the short term, this should bring you some much needed and much deserved funds, while keeping most of the community happy with the MIT terms intact. Honestly, the small amount of money would be a completely non-issue to game studios who have multi-hundred people on their payroll/projects.

(Step 2) : After Step 1, hire a few but competent people to help you with the technical work, even if part-time/contractual.

With some funding incoming with the new license, onboard maybe 1, perhaps max 2 people, to your project? Make sure these are people who have shown to be competent at making additions to the project and who understand well the philosophy of the project.

Having experienced devs with Dear Imgui should offload at least a good portion of the effort you feel like is wasted right now, these wouldn't be newbies.

Note that you don't have to remove yourself completely from the technical work. At least keep being there until you feel confident that they have a good handle on things, but try to be the mentor vs the one who does everything.

Think about the Linux project. Linus is the ultimate cop -- but he notes that he can't be the one doing everything. I mean, Linux is a much >>>> bigger project than Imgui. If Linus can make it work, why not you?

Whatever approach you'd choose, the goal here is to remove you as the technical bottleneck while keeping "doing things right".

(Step 3) : In the short term, focus on being "the manager": on being the point of contact between the entrepreneur and the technician(s)

And you know what, if it was me wearing the "manager" hat myself, the first thing I'd say is: "Dude! What is it with 100+ "unfinished" or "experimental" branches? Really? The longer you have those hanging around, the longer they will accumulate tech debt. PLEASE focus and find a way to get those features into master, before starting yet another endeavour.

"But, they are not quite to my liking!" -- I hear your say.

"Maybe so, but working software is a feature in and of itself" -- you will hear is my response. And also "you don't need for a feature to be perfect - it's more useful to have something that works well enough than something that doesn't exist"...

Also isn't it possible you underestimate people's responses to a changing API? I mean, if the docking interface changes from v1.95 to v1.98, people will adapt. It's not a huge deal.

Another example: No High DPI support because don't know how to handle the perfect case of some monitors at different DPIs? Dude: most people work with identical multi-monitors. And if people use it in shipping games, they use only one TV!... Make it DPI aware for the main monitor and mark the rest as a limitation, and make DPI adjustment an opt-in feature, if you must. With 4K gaming becoming more and more a thing, I'm sure it would be a lot more useful to have, than not.

Another example: no string_view because reasons? Make it an opt-in, compile-time option.

the point is... for god's sake.. 100+ unfinished branches is bananas-insane.

And also remember: shipping is a feature, and it's absolutely OK to have a fluid interface. Even Apple aggressively deprecates stuff; both hardware and software APIs, and there's nothing wrong with that. People will adapt to new / changed APIs, don't worry about that. If they don't want to, they can stick to the Dear Imgui version they use now.

As the manager, take a hard look at your bugs and issues, and create an actual prioritized work log for your contributors.... And speaking of which, primarily ask of the community contributors not to contribute "new features", but to contribute bug fixes, and to submit PRs for those, first.

Also I don't know to what extent you have a good test harness / automated test framework, but that would be a good thing to ask the community to help you with.

(Step 4) Make a plan for what comes next.

You already seem to have a good handle on this, at least on the technical level; you've alluded to where you want to bring Dear Imgui next, when you speak of the "next major things".

But you make no mention of how you'll get there. Which individual rocks, and in which order, you will step on to go from one side of the river to the other side.... The how is at least as important as the what..

Because otherwise you'll keep getting bogged down in the every day details, and you'll feel like you make no progress.

Yeah, it's boring to be the manager. But there's a reason they exist.

(Conclusion)

As my last thoughts, I'll just say that most people always overestimate what they can accomplish in the short term, and when people fail at accomplishing such short-term goals, even with all the effort, because of distractions, challenges, or lack of resources -- or whatever -- it can get depressing and lead to burnout.

But -- by the same token -- people who stick with it will almost always underestimate what they can do in the long term!

Just look at how far you've come since Dear Imgui in 10 years! It's nothing short of fantastic. You've stated yourself that initially you never thought the project would ever get so much adoption, yet here we are.

Again, congratulations are in order.

I wish you all the best.

ChristopherJTrent commented 1 month ago

removed

ocornut commented 1 month ago

@ChristopherJTrent As mentioned several times in the post, please try to not open new topics of discussion here. You can open new issues. Section 3.8 "ImGui Demo Vs Traditional Documentation" of the post has some notes about this. If your language bindings doesn't have comments you have a problem with the bindings IMHO. Nowadays we favor using https://github.com/dearimgui/dear_bindings which can emit full comments in the metadata. Ideally every language binding should carry the comments at minimum. Your IDE should always be able to tell you what's available. What's the language? As a workaround maybe keeping e.g. https://pthom.github.io/imgui_manual_online/manual/imgui_manual.html available may be helpful.

ChristopherJTrent commented 1 month ago

removed

ocornut commented 4 weeks ago

@spiriapbergeron I didn't mean to ignore your lengthy post. Thank you! I've read it. I will try to eventually answer you privately at some point.

spiriapbergeron commented 4 weeks ago

No worries

Sent from my iPhone

On Oct 24, 2024, at 11:39 AM, omar @.***> wrote:



@spiriapbergeronhttps://github.com/spiriapbergeron I didn't mean to ignore your lengthy post. Thank you! I've read it. I will try to eventually answer you privately at some point.

— Reply to this email directly, view it on GitHubhttps://github.com/ocornut/imgui/issues/7892#issuecomment-2435632805, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMFB7OGVS2PJBHGKPSZ66S3Z5EIBJAVCNFSM6AAAAABMSK5K62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZVGYZTEOBQGU. You are receiving this because you were mentioned.Message ID: @.***>