Graphical Interfaces

The writing of graphical programs is often an interesting endeavor. Many systems have their own sets of customs and limitations and enforce certain approaches to graphical program design that ofttimes influences the view of the system as a whole. For the purposes of this thread, a graphical program is any program that outputs visual information beyond the common definition of computer text. With a suitably expressive character set and controlling features, a TUI (Text User Interface) can be a fine and efficient option. Some graphical systems enable pixel-perfect precision, whereas similar systems enforce vector graphics as the unit. With the creation of the WWW and graphical browsers, graphical programs could become more prolific in some areas, but the WWW has its own set of rules that violating can cause pain. Certain systems combine hardwired and smooth graphics with more flexible grids. Many graphical systems have the concept of a mouse and windows, whereas others use the entire screen for programs, and yet more vary the input from buttons to keyboards to mice to fingers to voice to an entire body and yet more. There are those that are experimental and others that are decades old, any of which can have associated baggage of many forms. Some methods are bound to languages and others provide more generic interfaces. Some graphical systems are designed for single purposes and others are significantly more free. The distinction between the illusion of two and three dimensions is also becoming a noteworthy topic when designing graphical interfaces, along with the associated input methods. The system metaphors vary from images, to books, to movies, to locations, to yet more. Some graphical systems intend for multiple means of viewing, whereas others have a single canonical method. Feel free to use this thread to elaborate on your favorite aspects of graphical programming and the systems that enable this, including those already mentioned. Design from the perspectives of man and machine is certainly relevant. Lastly, this is also a thread to seek advice or troubleshoot when writing these programs, as some environments can make this difficult or unwieldy.

I'm struggling to find a decent and simple way to create a simple graphical program under X11. All I'd like is to display rows of text dynamically resizing based on the window space and I'd also like the ability to draw graphics in these rows, which is why I can't do it in the TTY well enough for my liking. I'd prefer for this to be simple; there's no reason a program this simple should consume even half a megabyte of storage. I really think I'm going to end up cannibalizing Emacs for its display code, although I was already planning on doing that further down the road. I'd prefer to use a small language and avoid C, but all of the Forth X11 bindings are huge and most other languages are larger.

>>3116 You should search for a language that has some version of XCB, which is a language-agnostic protocol. The C version is generated from the XML files that define it too, and some other languages do it as well (Guile's version directly reads the spec as a language that outputs Guile functions, it's pretty cool) but most are content with just binding to the C version. I think there's a Rust version as well.

>>1403

>>3126 I suppose there's no real way around this. I'll probably use a Scheme as the most lightweight base that won't drive me mad. I've been considering Chez Scheme, as it can produce good standalone programs, but I've not been able to find anyone with experience using it for something like this so far.

>>3134 This thread focuses on programming outside of the desktop; to make an example, that thread isn't for phone graphics. The two seem distinct enough for me.

I have a serious hard-on for aircraft HUD interfaces. I have no idea what went into the design of these things but they're awesome.