Neal here- Still very much under development. The public repo is now several months behind. I have been contracted to integrate my project into a particular product, which I have been working this last month. To do this I have been working on the embeddable version, which now can run in Unreal, Vulkan, and OpenGL. It also works on imgui docking branch. Anyways, hopefully I will be able to upstream all my work and make it public. I do intend to continue this project as time permits.
I do find this an interesting project. I don't think it will serve my purpose as i'm already comfortable with my chosen text editor.
I think many developers/programmers have already picked their poison - what advantages would switching to Ned have? Would newcommers try it.. or resort to VSCode, NeoVim, etc.
Not suggesting it's wrong or a waste of time. Certainly not! I am always happy to see various alternatives out there in various sections of computing... even the likes of GNU Hurd still keeping itself going!
There has been projects where I've been very tempted to use IMGUI as it is an easy/quick approach than building a website or commonly known GUI managers. (WPF, Qt, Gtk, etc)
The problem is - these projects are not about creating text editors, but some GUI Windows (or Windows) that solves problems with check boxes, buttons, and text areas. The problem is ALWAYS when the customers says "Ooh.. it would be good if we can do this!" which, for example, is supporting a Map.. like Gmaps.. which can be supported on the web or on traditional UIs easily.
Do I have the time to support a new feature? Unfortunately.. I dont! I end up using the tools or libraries that DO have these features available. In this example, I can just put together a website using Leafletjs.
Long story short.. as much as I would love to use an Immediate Mode UI to solve a problem... it sounds like a great idea... until it isn't.
This is based on the Dear ImGui library/framework [0]. It's not intended, strictly speaking, for standard desktop applications. It's intended for applications that use 3d rendering, like games or CAD.
Although you could certainly use it as a desktop editor if you wanted to, I think the real value is in embedding.
Tried it on Windows on a powerful workstation. Felt sluggish.
The framerate seems to be capped as 60Hz. My monitor is running at 240Hz.
Removing the framerate limit could help.
This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh rate the entire time (since it was developed for games, not normal desktop apps), but it never materialises, and the hacks we all implement ourselves stop working as they update the code etc.
Everyone seems to want 9234567345863489634589 fps, when that's IMO completely absurd for a normal desktop app, e.g. editor! What you actually want is low latency, not constant massive bandwidth and power usage. If all your normal desktop apps constantly ran at uncapped FPS, your computer would scream and laptops wouldn't last 5 minutes on battery.
And the worst thing is that with GPU rendering it's pretty easy to introduce extra latency - if you buffer too much, miss sync events etc - and there's inherently more latency to the rendering process than just writing a pixel color into a framebuffer and having it scanned out to the screen.
The whole point of >60FPS would be to able to reduce the delay between the user action and the results appearing on the screen.
The irony is just like with manufacturing and CPUs, the secret to getting high throughput necessary for high FPS is deep pipelining - meaning more delays compared to just drawing stuff.
The parallel of this in games has been frame generation, and fake frames - the way this is implemented that the game waits an extra frame's worth of time, then starts generating an interpolated frame between the two states, which adds extra time as well.
I propose, that instead of FPS, gaming benchmarks should move to the metric of action-to-pixel (ATP). For this metric, the FPS(or frame time) is a lower bound - if your game runs at 60FPS, your frames take 16.66ms to render - so by definition you can't react any faster than that.
Not sure if anyone's working on this, but this would be a nice way to combat the framegen BS that's going on in the games industry right now.
It blows my mind how controversial this obvious point is; makes me wonder if people also keep their washing machines running at full tilt without any clothes in them.
Wouldn't it look stuttery if the user tried to drag windows or other widgets with a limited framerate?
> What you actually want is low latency
High frame rates directly contribute to lowering latency.
I guess I'm the polar opposite of you here, I heavily prefer low latency/high refresh rates over low CPU/GPU usage, as long as the machine is plugged in to a power source.
Maybe it's car analogy time: this is a bit like saying, well it's fine if my car is redlining 24/7, as long as it gets the speed I want when I happen to be on the highway.
Nobody is saying they want to tolerate some horribly laggy interface for the sake of lower CPU usage. The point is simply about not wasting enormous amounts of power when it's not needed.
I would agree with that for desktop apps. Not refreshing unless needed. And this is not too difficult to do. But still, when other editors are refreshing at 240Hz, simply scrolling text or hovering over the file list seems sluggish at 60Hz.
> This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh rate the entire time
I don't know what to tell you when you're fucking with an immediate mode UI library...
Unless you are targeting Atari 2600, immediate mode still retains state in the form of a frame buffer. Your video game should not repaint if nothing has changed since last frame, e.g. when paused, let alone a text editor.
So you're arguing that the definition of an IM UI library necessarily includes running at full screen refresh rate the entire time?
Then how is it that many people, myself included, are able to hack fix this to only update when required? Why does the imgui dev himself promise official support for this?
Retained mode (for desktop apps) was/is primarily about creating an object heirachy that allows you to minimize full redraws and the like --- you'd assume, for something immediate mode, that you're basically asking to push frames directly without any barriers
Hey Ned developer here, there is a target fps slider in settings. I am able to get 800+fps on my MacBook m4. There is a mode where it reduces fps until user input on Mac to save battery life. However this only works with shaders turned off, as the shaders depend on continuous rendering.
Fifteen years ago I started to develop mild neurological symptoms. Mostly headaches, some minor muscle twitches, and some weird vision issues. I started working with first my GP and then with a neurologist to try to get to the bottom of it. The investigation was leading towards some form of optic neuropathy. In parallel I moved to a new job. All of my symptoms went away and in retrospect at the time all of the symptoms had started when I'd started that job. The fluorescent lighting near my desk there was terrible and as far as my doctors and I could figure out that was likely the cause of it.
Not the OP, but yeah that used to bother me when I was younger.
As did any CRTs running below 75hz
My “super power” used to be that I could tell what refresh rate a VDU was operating at just by looking at it. Well, I couldn’t tell past 80hz. But anything below that I could.
Most lights try to avoid flicker in the design, but bad/failing ones can drive one nuts. E.g. fluorescents flicker at 120 Hz (2 crossings per cycle) but the phosphor coating carries some glow and that they stay on for ~80% of the cycle time anyways makes it a lot more bearable that if it were an idealized instantaneous 50% duty at a 60 Hz rate.
So many "hackers" apparently did not hear about adaptive refresh. There is no need to update a static image every 240fps. You only need to increase the refresh rate for animations like scrolling, like in... everywhere??? Android, macOS, Chromium, Qt, and GTK(?) do this.
I'd rather run my editor of choice in a terminal with shader effects like these (bloom, burnin, scanlines, curvature). Cool Retro Term does these effects very well, but it's also not a very good terminal.
A few weeks ago I tried to get claude code to embed this in a demo IMGUI app and it really struggled. That's not too meaningful, but maybe I'll give it another shot with the tried and true method of using my own head.
I'm always in the looking for an alternative to vscodium. This one is surprisingly feature complete for something meant to embed in 3D renderers. I'd like to see what people do with it.
I have recently tried it again and it seems to have gotten worse that what I remembered. The interface was really hard on my eyes. I spent a little time trying to tweak the theme but I don't think that was the problem but the font rendering. I also noticed some weird layout bugs in the tab buttons. So not as smooth as I previously remembered.
I do appreciate they have the option to disable the big sign-in button however there are other account related UI I still can't disable.
The main feature that keeps me from moving to any other editor is the vscode/vscodium feature of clicking and dragging files to insert links and embed images in markdown files. Weird that no other editor has this.
Cool project and I really do not want to tell people what to do with their hobby projects, but this project would have also been very cool (and likely far more used) as a neovim frontend.
I used to write a lot of code with a fullscreen transparent terminal window over a low-contrast desktop background, like a misty mountain or a nebulous celestial object. The code was clear close up, but distant bystanders could also appreciate the wallpaper. It felt magical, like I controlled the computer so deeply that I could summon and dismiss text directly over the nature scenery of my choosing -- zero pixels lost to menus or borders. It was beautiful!
This works really well until your transparent terminal is overlapping some other text, or worse, another transparent terminal!
Beautiful as it was, I eventually stopped setting this up.
Neal here- Still very much under development. The public repo is now several months behind. I have been contracted to integrate my project into a particular product, which I have been working this last month. To do this I have been working on the embeddable version, which now can run in Unreal, Vulkan, and OpenGL. It also works on imgui docking branch. Anyways, hopefully I will be able to upstream all my work and make it public. I do intend to continue this project as time permits.
I do find this an interesting project. I don't think it will serve my purpose as i'm already comfortable with my chosen text editor.
I think many developers/programmers have already picked their poison - what advantages would switching to Ned have? Would newcommers try it.. or resort to VSCode, NeoVim, etc.
Not suggesting it's wrong or a waste of time. Certainly not! I am always happy to see various alternatives out there in various sections of computing... even the likes of GNU Hurd still keeping itself going!
There has been projects where I've been very tempted to use IMGUI as it is an easy/quick approach than building a website or commonly known GUI managers. (WPF, Qt, Gtk, etc)
The problem is - these projects are not about creating text editors, but some GUI Windows (or Windows) that solves problems with check boxes, buttons, and text areas. The problem is ALWAYS when the customers says "Ooh.. it would be good if we can do this!" which, for example, is supporting a Map.. like Gmaps.. which can be supported on the web or on traditional UIs easily.
Do I have the time to support a new feature? Unfortunately.. I dont! I end up using the tools or libraries that DO have these features available. In this example, I can just put together a website using Leafletjs.
Long story short.. as much as I would love to use an Immediate Mode UI to solve a problem... it sounds like a great idea... until it isn't.
This is based on the Dear ImGui library/framework [0]. It's not intended, strictly speaking, for standard desktop applications. It's intended for applications that use 3d rendering, like games or CAD.
Although you could certainly use it as a desktop editor if you wanted to, I think the real value is in embedding.
[0] https://github.com/ocornut/imgui
Yes I am aware that IM UI's are popular for games - level editors etc.
Just nice to see other possibilities.
Writing a text editor is like writing a compiler; the point isn't adoption, the point is in the learning
100%
Tried it on Windows on a powerful workstation. Felt sluggish. The framerate seems to be capped as 60Hz. My monitor is running at 240Hz. Removing the framerate limit could help.
This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh rate the entire time (since it was developed for games, not normal desktop apps), but it never materialises, and the hacks we all implement ourselves stop working as they update the code etc.
Everyone seems to want 9234567345863489634589 fps, when that's IMO completely absurd for a normal desktop app, e.g. editor! What you actually want is low latency, not constant massive bandwidth and power usage. If all your normal desktop apps constantly ran at uncapped FPS, your computer would scream and laptops wouldn't last 5 minutes on battery.
And the worst thing is that with GPU rendering it's pretty easy to introduce extra latency - if you buffer too much, miss sync events etc - and there's inherently more latency to the rendering process than just writing a pixel color into a framebuffer and having it scanned out to the screen.
The whole point of >60FPS would be to able to reduce the delay between the user action and the results appearing on the screen.
The irony is just like with manufacturing and CPUs, the secret to getting high throughput necessary for high FPS is deep pipelining - meaning more delays compared to just drawing stuff.
The parallel of this in games has been frame generation, and fake frames - the way this is implemented that the game waits an extra frame's worth of time, then starts generating an interpolated frame between the two states, which adds extra time as well.
I propose, that instead of FPS, gaming benchmarks should move to the metric of action-to-pixel (ATP). For this metric, the FPS(or frame time) is a lower bound - if your game runs at 60FPS, your frames take 16.66ms to render - so by definition you can't react any faster than that.
Not sure if anyone's working on this, but this would be a nice way to combat the framegen BS that's going on in the games industry right now.
I promise it’s coming eventually but I don’t believe the custom version is hard to make to work either.
Oh wow, it's the man himself! I'm very sorry if I sounded ungrateful, imgui is the best damn thing to happen to UI coding ever <3
I will be so extremely happy when this lands, and imgui is already such a blessing.
It should be running at 0 fps, then when there is movement it should run at refresh rate.
It blows my mind how controversial this obvious point is; makes me wonder if people also keep their washing machines running at full tilt without any clothes in them.
Wouldn't it look stuttery if the user tried to drag windows or other widgets with a limited framerate?
> What you actually want is low latency
High frame rates directly contribute to lowering latency.
I guess I'm the polar opposite of you here, I heavily prefer low latency/high refresh rates over low CPU/GPU usage, as long as the machine is plugged in to a power source.
Maybe it's car analogy time: this is a bit like saying, well it's fine if my car is redlining 24/7, as long as it gets the speed I want when I happen to be on the highway.
Nobody is saying they want to tolerate some horribly laggy interface for the sake of lower CPU usage. The point is simply about not wasting enormous amounts of power when it's not needed.
I would agree with that for desktop apps. Not refreshing unless needed. And this is not too difficult to do. But still, when other editors are refreshing at 240Hz, simply scrolling text or hovering over the file list seems sluggish at 60Hz.
> This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh rate the entire time
I don't know what to tell you when you're fucking with an immediate mode UI library...
Unless you are targeting Atari 2600, immediate mode still retains state in the form of a frame buffer. Your video game should not repaint if nothing has changed since last frame, e.g. when paused, let alone a text editor.
So you're arguing that the definition of an IM UI library necessarily includes running at full screen refresh rate the entire time?
Then how is it that many people, myself included, are able to hack fix this to only update when required? Why does the imgui dev himself promise official support for this?
Retained mode (for desktop apps) was/is primarily about creating an object heirachy that allows you to minimize full redraws and the like --- you'd assume, for something immediate mode, that you're basically asking to push frames directly without any barriers
The most efficient way to answer the "no redraw needed" question is orthogonal to the "question" of whether or not to do redraws when not needed.
Hey Ned developer here, there is a target fps slider in settings. I am able to get 800+fps on my MacBook m4. There is a mode where it reduces fps until user input on Mac to save battery life. However this only works with shaders turned off, as the shaders depend on continuous rendering.
Does it bother you when you see flourescent lighting that's connected to 50/60 Hz mains power and you just see violent flashing?
(edit: This isn't snark, I can't see changes that fast, but I know what they look like slowed down and that other people may be different to me.)
Fifteen years ago I started to develop mild neurological symptoms. Mostly headaches, some minor muscle twitches, and some weird vision issues. I started working with first my GP and then with a neurologist to try to get to the bottom of it. The investigation was leading towards some form of optic neuropathy. In parallel I moved to a new job. All of my symptoms went away and in retrospect at the time all of the symptoms had started when I'd started that job. The fluorescent lighting near my desk there was terrible and as far as my doctors and I could figure out that was likely the cause of it.
Not the OP, but yeah that used to bother me when I was younger.
As did any CRTs running below 75hz
My “super power” used to be that I could tell what refresh rate a VDU was operating at just by looking at it. Well, I couldn’t tell past 80hz. But anything below that I could.
Most lights try to avoid flicker in the design, but bad/failing ones can drive one nuts. E.g. fluorescents flicker at 120 Hz (2 crossings per cycle) but the phosphor coating carries some glow and that they stay on for ~80% of the cycle time anyways makes it a lot more bearable that if it were an idealized instantaneous 50% duty at a 60 Hz rate.
God bless LEDs with some capacitance though...
It's actually not even 60. The FPS target is configurable in the settings and for some reason the default is 57.
To all other comments in this thread.
So many "hackers" apparently did not hear about adaptive refresh. There is no need to update a static image every 240fps. You only need to increase the refresh rate for animations like scrolling, like in... everywhere??? Android, macOS, Chromium, Qt, and GTK(?) do this.
The embed ned is awesome. Will make ImGui engine editors that much more robust. Fantastic.
I’m going to tinker with this.
I'd rather run my editor of choice in a terminal with shader effects like these (bloom, burnin, scanlines, curvature). Cool Retro Term does these effects very well, but it's also not a very good terminal.
A few weeks ago I tried to get claude code to embed this in a demo IMGUI app and it really struggled. That's not too meaningful, but maybe I'll give it another shot with the tried and true method of using my own head.
I'm always in the looking for an alternative to vscodium. This one is surprisingly feature complete for something meant to embed in 3D renderers. I'd like to see what people do with it.
Have you tried zed? I've tried many alternatives and zed is a really cool project.
I have recently tried it again and it seems to have gotten worse that what I remembered. The interface was really hard on my eyes. I spent a little time trying to tweak the theme but I don't think that was the problem but the font rendering. I also noticed some weird layout bugs in the tab buttons. So not as smooth as I previously remembered.
I do appreciate they have the option to disable the big sign-in button however there are other account related UI I still can't disable.
The main feature that keeps me from moving to any other editor is the vscode/vscodium feature of clicking and dragging files to insert links and embed images in markdown files. Weird that no other editor has this.
From the video looks like it's already usable, with Lua or some other scripting language it could be a good alternative to vim or helix.
Cool project and I really do not want to tell people what to do with their hobby projects, but this project would have also been very cool (and likely far more used) as a neovim frontend.
Whenever I see someone putting transparency on the background of their text editor I immediately know we have absolutely nothing in common.
I used to write a lot of code with a fullscreen transparent terminal window over a low-contrast desktop background, like a misty mountain or a nebulous celestial object. The code was clear close up, but distant bystanders could also appreciate the wallpaper. It felt magical, like I controlled the computer so deeply that I could summon and dismiss text directly over the nature scenery of my choosing -- zero pixels lost to menus or borders. It was beautiful!
This works really well until your transparent terminal is overlapping some other text, or worse, another transparent terminal!
Beautiful as it was, I eventually stopped setting this up.
Same goes for OS terminals, it was fun for a while in Enlightenment, but really not usable.