Emacs comes to mind: it has a codebase stretching back to the 1970s and is still actively developed, with a dedicated following of users (myself included).

Emacs is not really the classical desktop-app. It's a terminal-app that just happened to also have a GUI.

I consider any user-facing application that presents its own interface and that a user runs on their own computer a desktop-app. Whether the UI gets rounded corners, animations and smooth scrolling is not important, and neither is whether your UI elements are submitted for display through an Wayland/X11 socket or through command sequences over stdout.

By that logic, any android or iOS-app would be also a desktop-application. As also any DOS-App and anything with curse-interface. What about interactive commandline-apps? Like a database-shell? They also have their own interface, it's just made of text.

Any DOS app with a curses interface is a desktop application, yes. Any terminal tool with a TUI is a desktop application. A command-line tool without an interface (just arguments and pipes) is not, because it does not aim to be interactive. A terminal tool that just asks questions is a bad desktop applications, but simple form apps exist in the GUI world too.

All UIs are made of text and symbolic visual elements. Whether you draw your button with unicode block characters, a GtkButton, a Flutter TextButton, or a HTML does not matter in the slightest from the perspective of being a desktop app or having a UI.

The reason an Android an iOS app is not a desktop app is because it does not run on a desktop. A minor distinction, but the way we use our pocket computers is different from how we use our desk computers and so we distinguish between them. The line gets beautifully blurred once you run the iOS app on macOS or Android app on Windows 11, but humans are bad at categorizing things in ways that remain consistent for more than a few years - just ask any biologist.

> Any DOS app with a curses interface is a desktop application, yes. Any terminal tool with a TUI is a desktop application. A command-line tool without an interface (just arguments and pipes) is not, because it does not aim to be interactive. A terminal tool that just asks questions is a bad desktop applications, but simple form apps exist in the GUI world too.

Ok, fair, but a very unusual definition.

> All UIs are made of text and symbolic visual elements. Whether you draw your button with unicode block characters, a GtkButton, a Flutter TextButton, or a HTML does not matter in the slightest from the perspective of being a desktop app or having a UI.

But it does matter for a _G_UI whether you have actual graphical elements, or just text. There is a significant differences in ability coming with those.

> The reason an Android an iOS app is not a desktop app is because it does not run on a desktop. A minor distinction, but the way we use our pocket computers is different from how we use our desk computers and so we distinguish between them.

Android and iOS do not run only on smartphones. People working on tablets, use them similar to the normal laptop/notebook/PC table-setup. Taking a classical PC-Desktop as the base of your definition falls apart very fast today.

> humans are bad at categorizing things in ways that remain consistent for more than a few years - just ask any biologist.

The established definition of desktop, mobile, gui, tui and commandline is pretty consistent for some decades now I would say.

I would say that the distinction between TUI and GUI - outside "how would I use this tool remotely" - is mainly one for the developer. Take ImGui (https://github.com/ocornut/imgui, an immediate mode GUI library) for example - the examples are much closer to TUI interfaces than a Swift UI app - the only difference between that an a terminal UI would be that the lines are thinner and that text has non-uniform spacing.

Does that make ImGui a TUI? Or make TUIs a GUI? Why are those thin visual lines graphical, if the slightly thicker visual lines drawn by your graphical terminal emulator with support arbitrary color precision and inline image rendition is not?

Maybe the issue is that it there is a terminal emulator to visualize the representation. But if an application that is not graphically heavy and needs an intermediary is a TUI, does that make most utility electron apps TUIs?

The difference between a TUI and a GUI is just an implementation detail, and these do not matter in the distinction of desktop app or not. Heck, some modern terminal UIs are more graphically appealing than some GUI apps.

And remember, the question was about desktop, not GUI specifically.

> The established definition of desktop, mobile, gui, tui and commandline is pretty consistent for some decades now I would say.

Considering that all good desktop apps were TUI apps 3 decades ago, that mobile apps are in their modern form has basically only existed for 1.5 decades, and that running mobile apps as desktop apps and the general merge between the disciplines is only a few years old at most, I'd say that this statement doesn't quite hold.

> Take ImGui (https://github.com/ocornut/imgui, an immediate mode GUI library) for example - the examples are much closer to TUI interfaces than a Swift UI app - the only difference between that an a terminal UI would be that the lines are thinner and that text has non-uniform spacing.

What I see there is a spatial interface with complex layout, z-axis and graphical elements. A bit hard to replicate on a normal terminal.

> Does that make ImGui a TUI?

TUI and GUI are not defined by the actual complexity of a real application, but the environment which gives them theoretical abilities. With a GUI, you can have pixel-perfect control over every element. With a TUI, you are normally limited to character-level of control. Of course can you also use pixels without a desktop, but you would still leave the terminal-environment and enter the framebuffer for this or something similar. Though, to be fair, at this point it indeed can become a bit fuzzy.