Linux native applications

I want to make a simple text editor to run natively on linux. I looked at Qt and GTK, but I really don't like them. Can I go a level deeper (e.g. using only X11)? How would I learn to do this and what documentation might be useful? I have done some game development using libraries like SDL. Would it be a dumb idea to write a native app in the same general way as I write my games? That would be familiar, but is probably not the best way to write a normal user interface. If you want to share anything to do with writing native linux applications please do so, even if it doesn't answer my questions above.

There really isn't a "native Linux" like there is in other operating systems, because it's not really a centrally defined software stack (see also the Linux vs GNU/Linux debate). It's not like Windows, where there's a single "canonical" UI toolkit that's deeply tied to the underlying system. The closest you get is a desktop environment like KDE opting to do everything with the same GUI toolkit.

You can use an immediate GUI library such as Dear ImGui, it's not ideal because of integration, theming and accessibility, but it's certainly a possibility, and some software like RemedyBG uses it.

>>37011 I think that some users here like Motif.

>>37021 I guess you're right, I was having trouble because I didn't really recognize that. But surely those GUI toolkits are written in terms of some common underlying system right? >>37026 This looks really interesting, will definitely give a look. Thanks >>37027 This looks nice and simple, worth a look. Thanks

>>37011 You could use straight X11 like you mentioned. Just read the X11 programming manuals. But I don't see why you wouldn't use GTK or Qt

>>37011 >Would it be a dumb idea to write a native app in the same general way as I write my games? I think that this is actually a genius idea. >>37011 >if you want to share anything to do with writing native linux applications please do so, even if it doesn't answer my questions above. What point we reached, when we need to specify that something is native, instead a of a fuarrrked up packed browser with lots of css and html to do a basic interface. X11 is actually pretty damn easy, you can just get the manual and read. I still like your first idea better. See, if you just make a normal editor, there won't be any attractive points on it. But an editor which is not only fast, but has some high performant visual aspects to it, not the interpreted CSS and JS crap, then you will really be ahead of the competition.

>>37032 The "common underlying system" that these GUI toolkits are written in are graphics primitives,such as OpenGL or Vulkan. You could write your own GUI library using SDL2 or something similar, although it'd be quite a bit of work.

>>37011 Maybe give Tcl/Tk a try. It's lightweight, stable, has "native" look and feel since v8, has bindings for whatever weird language you use, and is well supported across platforms and distros. It was the compromise candidate between GTK and Qt back in the day and it's still around and kicking.

python tk or you could just go super deep and just output to frame buffer, bypass x11 entirely

>>37011 Although you're trying to write something Linux-specific, that kernel doesn't provide a graphics toolkit. You could write something directly for Direct Rendering Manager, but the compatibility of that will be poor. You can write a GUI just fine in straight SDL2 or Xorg/X11 and the resulting program will be cross platform, but having to implement every single widget will get old fast. I would recommend either GNU ncurses or GNUstep. GNU does already have the GNU Emacs OS, with a built-in editor, so maybe try that instead and all wanted functionality with emacs lisp?

>>37032 There is a common underlying system, but probably not the graphical system I suspect you're going for: https://www.freedesktop.org/wiki/Specifications/ These are the standards that define behaviors of a cross-operational desktop, incl. icons, sound themes, .desktop entries, menus, cursors, and so on. It has no standard for GUI application concepts, but it's the closest thing to a widely agreed-upon set of standards.

Maybe helpful or maybe not, but have you looked into this guide to programming the kilo text editor? https://viewsourcecode.org/snaptoken/kilo/ It's a small text editor and this guide goes step-by-step into how to program it. Maybe not relevant to your goals, but maybe it is. It was an interesting and fun project that I have followed before when writing a Linux text editor. You don't need very much to write for Linux, but for a gui rather than a tui you should consider a toolkit like qt, gtk, sdl, or hell, even electron.

>>37108 >>37131 +1 for Tk it's quite interesting how much you can mold it

Nobody's really hit the button on the head in describing what "a layer deeper" is on Linux yet, so I'll just say it. The "level deeper" you're talking about is called a framebuffer. There's some more to it like potentially handing off to the video card and rendering through it instead, which most GUI frameworks try to do for performance reasons these days, but at its core, both the X Window Server and Wayland hand your program a framebuffer, an array of pixels that you can manipulate and tell X or Wayland to render. X does this a bit more indirectly unless use you use XShm, but that's still the underlying idea, just over sockets instead of a shared memory buffer between your program and the windowing server. There exists some software that handle graphics that way (often with a library like pixman built for drawing to framebuffers -- pixman in particular underlies cairo, which in turn underlies GTK), see foot[1] for an example, but it's something you really don't want to have to do for anything much more complex than a terminal emulator. 1: https://codeberg.org/dnkl/foot

>>37011 What you want, I would guess, it to do all the graphics business directly yourself. You could do this by using something as simple as pure OpenGL. It would even be cross platform if you chose to write it yourself in this way. The actual rendering of a GUI doesn't usually require platform-specific code, just manually writing to buffers of pixels. >Would it be a dumb idea to write a native app in the same general way as I write my games? In general, yes. Games use input polling whereas GUIs wait for input. Typically, the difference between these two is changing a single function somewhere (for instance glfwPollEvents goes to glfwWaitEvents). This is to avoid hogging resources on the host system by only rendering frames when you receive an input and need to update the GUI. Your PC would probably be quite a bit slower if every application was spinning its wheels at 60fps, rendering the same frame over and over. >Can I go a level deeper (e.g. using only X11) You typically don't need to, as I have mentioned before. The main OS-specific stuff you need to do in GUIs is stuff like the clipboard and drag-and-drop. Anything that requires you to interact with other applications or the OS itself. Luckily a lot of this stuff has cross-platform libraries (such as glfw for creating windows). It isn't usually benefitcial to do these things yourself, since you end up just writing a big chain of if-statements and pre-processor stuff to call a different function to do the same thing based on the current platform.

>>37011 https://en.wikipedia.org/wiki/Xlib surprised nobody has mentioned it yet.

>>37011 I made my own UI system in a game here. https://git.lain.church/Santificado/magos/src/branch/master/src/ui.c What i would say is that it is not as difficult as you might think but it is not easy, there's lots of things that you have to consider and without a IME UTF-8 text insertion becomes a lot harder, plus text rendering is a pain, in my case i can go with bitmap rendering because i opted to only use latin character set, but for your case, if you want your text editor to work in lots of languages, it will be difficult to render the text with all characters you want, you probably want to go with partial rendering which is also a pain to setup because of the "dirty" flags.

>>37370 Is that really the look you can achieve with tk? I always thought it was stuck with that sort of "retro" look. Pic looks as though you styled it in fvwm or something. I ask because I am actually planning on using a fvwm/tk combination to make a nice desktop environment of sorts

>>38351 >surprised nobody has mentioned it yet. neither did ballbusting

>>38351 But this poster did mention it. >>37034

>>37011 xcb + cairo considering you want to write a text editor, you are going to have to write your own widgets because the textbox widgets in the popular toolkits don't support the stuff you probably want (multiple cursors, buffering, syntax highlighting, auto-completion, etc.) cairo is slow compared to opengl or even sdl, but you can get something resembling a scintilla widget in just a matter of days (if not hours)

>>37011 You may be interested in xedit and nedit (both appear to use X11 only)

>what documentation might be useful? https://www.x.org/releases/current/doc/libxcb/tutorial/index.html#helloworld and if you decide to use cairo https://www.cairographics.org/manual/cairo-XCB-Surfaces.html

>>38346 >Nobody's really hit the button on the head in describing what "a layer deeper" is on Linux yet Neither did you with your post. The native Linux framework for rendering is DRM/KMS which X11 and Wayland use under the hood. You can write GUI programs targeting it directly without requiring a window server at all. mpv is such a program which has a DRM backend with hardware accleration rendering.

>>37011 Depends. You could code it for X11 directly. You could use Wayland. You could use LGVL. Linux is extremely fragmented.

Gio is a library for writing cross-platform immediate mode GUI-s in Go. Gio supports all the major platforms: Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD and WebAssembly.

>>38346 >>38469 thank you i think there needs to be a clearer path for people who *want control* over *every pixel* of their screen easily for their gui stuff, that layer must become unhidden right now i am working on something that essentially is displaying cairo graphics, simple shapes with line connections between them, as an 'overlay' on the screen. doing some unit tests, i can get the correct shapes and effects nicely, the best results, in a windowless/borderless render-space-thing, using Cairo with SDL2 and Xlib the only thing I can't figure out is 'transparency', as I don't think SDL2 alone has that capability, it must be paired with openGL from what i'm reading... adding GTK to the mix didn't really solve anything, but I haven't tested extensively. also it might be novel just to specialize notcurses for the linux tty and just render everything out to the terminal & never even have to start an x session really >:D

>>39088 >immediate mode IMO the rise of immediate mode GUIs for general purpose use because they're easy to make is a huge mistake.

>>37011 >>37034 xorg actually does have a native gui toolkit. Try installing xedit or xcalc. Although it's not robust, you can't theme it outside of changing colors and fonts and don't expect desktop integration.

>>37011 >simple text editor It’s a complex as fuarrrk problem domain good luck

>>39331 I don't think it is. IDEs are more complicated, but just a text editor is not. Font rendering is also somewhat complicated, but not massively thanks to the fact that modern computers are fast enough to allow very sub-optimal implementations.

>Font rendering is also somewhat complicated just use libfreetype ffs

>>39333 freetype + harfbuzz, you need font fallbacks, then split your string depending on availability of chars in font (remember chars != 8 bit bytes in unicode). cool, then you apply harfbuzz shaping which does kerning and replaces chars by glyphs. sometimes multiple chars are a single glyph. then use freetype to render the glyph which can be in several formats like monotone, greyscale or BGRA. you also need to have a cache to avoid repetitively calling freetype. if your app is multithreaded, make sure to guard freetype since it's not threadsafe. then depending on your rendered, AFTER you convert to RGBA, you allocate a texture, so again make sure you have a cache to avoid doing this redundantly. all cool right? well no some glyphs are fixed size so you must do the appropriate scaling down and calc the x advance manually. also depending on lang x advance and x offset and blaa blaa blaa, you have to know how to use all this stuff to display the chars. "bro just use freetype lol". im sure you only just learnt to do print("hello world")

>>39343 Academic approach to make a simple problem complex. Realistically you only need english. So render your letters once to a texture and save offsets for letters. Once you got that its just a basic opengl shader that renders each char as a textured quad with offset. There you go you can render any english text. Thats like 3-4h depending how lucky you are with google finding the right commands to get the first step done.

>>39332 I guess it depends on what you’re comparing it to in terms of complexity. Good luck OP I hope you learn a lot and have fun

>>39376 >Realistically you only need english. the realistically you only need xyz thing is why most software ends up being such an utter crap. no offense, i kinda get where it comes from but i'm just so fuarrrking sick of this thing

>>39387 Who does minimal software? Modern standard is exact opposite. Most use libraries that try to solve everything. Result is massive codebases with ample room for errors and bad performance due sheer size.

>>39394 People who say things like this have never written a single program that has ever been used by anyone besides themselves, and are probably teenagers. Less can be more, but it isn't necessarily so. Being able to display and edit text with non-English characters is a useful feature; a lot more useful than you'd think. Getting rid of it in the name of minimalism is like a media player not supporting subtitles in the name of minimalism.

>>39376 even in english stuff like kerning and replacing chars with a single glyph happens. your approach is the fool one and why your text will look like soykaf since you're a dev with no aesthetic taste

>>39401 >renders each char as a textured quad with offset thats kerning... dumbfucks always blaming the poster for personal inadequacies

>>39399 people who say things like this understand that it IS a personal hobby project... Getting done on limited time > "could be useful"

>>37011 You're going to have an easier time just using acme, OP. It's got all you need.

>>39567 i see a splashscreen to hide the yucky terminal while my display manager loads

>>39567 There are also dialog and cdk which simplify using ncurses https://invisible-island.net/dialog/ https://invisible-island.net/cdk/ these were pretty much the first linux UIs to become popular.