10 years of Dear ImGui (long post) #7892
Comments
1. STATISTICS / SOME NUMBERSFeatures:
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! 2. THE STORY OF DEAR IMGUI / EARLY TIMELINE2.1. MY EARLY PROGRAMMING EXPERIENCES & USER INTERFACESAs 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:
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.
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.
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).
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 JAPANIn 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 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.
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).
2.3. MEDIA MOLECULE, WRITING A NEW LIBRARYIn 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).
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) IMGUIThe 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.
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. |
3. WHAT WENT RIGHT3.1. INCREASED ADOPTIONUndoubtedly, the amount of people and teams using Dear ImGui have been growing. Many in-house toy engines, research projects 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 SUPPORTProjects often live and die by their maintenance past the initial release.
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 USEAnother of Dear ImGui's qualities is obviously its API. "Minimize state synchronization." 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. 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, EAVESDROPPINGI tend to care about people's needs and try to listen to everyone. Some of the things I do:
3.5. RUNTIME PERFORMANCEDear 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 FEATUREEncouraging people to build the library themselves had some valuable properties:
(
3.7. CATCHING USER MISTAKESThe library is littered with descriptive asserts and error checks. 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. 3.8. IMGUI DEMO vs TRADITIONAL DOCUMENTATIONIn 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!
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. 3.9. BACKENDSThey 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 INTEGRATIONWe 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 SUITEIn 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. Running_Dear_ImGui_Test_Suite_.Fast_Mode.mp4(Running Dear ImGui Test Suite, in Fast Mode, with full rendering enabled) Embracing regression tests have been an enormous time-saver. Not sure what a given piece of code is for? 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 HISTORYAll GitHub issues are carefully labeled and cross-linked to increase information discovery. Large commits doing many different things are avoided. More focus has been put into the Wiki in recent years 3.13. FUN COMMUNITY EVENTSThe 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)
We should do more of these :) 3.14. GREAT THIRD-PARTY ECOSYSTEMAs featured in our Useful Extensions wiki page there is a striving community of extensions.
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 WRONG4.1. BEING A JANITOR + A COPTending 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. -> I will need to learn to take a little more distance with the community. 4.2. ANSWERING TOO FASTFor years I have been too reactive with answering questions. Nowadays I force myself to not answer every question in order to leave room for others to engage. -> Again, I will need to learn to take a little more distance with the community. 4.3. DROWNING IN THE ATTENTION ECONOMYRequests 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. 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 CONTRIBUTIONSI 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. -> 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. 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. 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, ADHDI 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. 4.7. UNPLANNED CAREER CHANGEDear 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. 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. 4.9. LACK OF VISIBILITY OF SOME FEATURESDear ImGui has so many features that people don’t quite know everything.
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 COMMUNITIESA few years ago, I caved to recurrent requests to open a Discord.
I thought it was detrimental to information quality, to the community and to the software itself. 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. |
5. STRATEGY OF PACING GROWTH & CROWD CONTROLThis is perhaps one of the least obvious aspects of my long term vision toward Dear ImGui. Dear ImGui already has many users and a continuous, overwhelming flow of support requests. 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. This is partially why I have intentionally under prioritized features such as:
I must however say that I am NOT against those things. About accessibility (*edit*: this was added a bit after the initial post) 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!!!1The 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. 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:
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. 6.1. BETTER FONT SUPPORTBACKEND 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. 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 SCALINGWhile they are ways to provide DPI/scaling support they are currently mostly left to user 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 ISSUESBefore 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).
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.
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 HELPERSA bunch of ideas have been on hold for fear of "breaking too much & too often" 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 MECHANISMSImplement/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 MOREI 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. |
7. FUNDING 💰Nowadays I am generally getting enough to keep working on Dear ImGui!
The software is still largely underfunded:
It is a lots of work to get funding.
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 HELPDEVELOPMENT & COMMUNITY
FUNDING
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! On so many more productive and fun years! 🙏 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! |
|
@ocornut thanks so much for the amazing work over the years - on to the next 10 years! |
|
@ocornut Thank you and the community for creating Dear ImGui! Very interesting read. Your work is an inspiration ❤️ |
|
@ocornut Thank you for such amazing library. You work literally sparked in me joy to program again. |
|
Here's to the next 10! 🍻 |
|
Thanks for sharing your thoughts, it was a very nice read. And quite the opposite of "unstructured"! |
|
I found this really insightful and informative. There's a lot contained here that wasn't obvious or expected to me. |
|
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?
|
|
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 |
|
Very good post, good info. |
|
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! |
|
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. |
|
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!!! |
|
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! |
|
Congrats on 10 years! Thank you for your incredible efforts! |
|
Great Great post; Thanks! I learned a lot from it. |
|
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! |
|
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! |
|
@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. |
|
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. |
|
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
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 3. API Suggestion
|
|
Wow, time flies! Great job & amazing read, specially the personal aspect! |
|
Congratulations :) @tpecholt https://github.com/ocornut/imgui/tree/features/string_view |
|
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 ! |
|
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. |
|
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! 👍 |
|
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! |
|
Long read indeed, but very interesting. Thank you for all the effort you put in. |
|
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! |
|
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 |
|
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! |
|
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 ❤ |
|
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?) 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. |
|
removed |
|
@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. |
|
removed |
|
@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. |
|
No worries
…Sent from my iPhone
On Oct 24, 2024, at 11:39 AM, omar ***@***.***> wrote:
@spiriapbergeron<https://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 GitHub<#7892 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMFB7OGVS2PJBHGKPSZ66S3Z5EIBJAVCNFSM6AAAAABMSK5K62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZVGYZTEOBQGU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
and others
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 #7892 (comment))
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 #7892 (comment))
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 #7892 (comment))
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 #7892 (comment))
7. Funding
8. How To Help
The text was updated successfully, but these errors were encountered: