In Thu, 1 Jul 2021 23:17:33 +0200 Hiltjo Posthuma <hil...@codemadness.org> wrote:
> On Thu, Jul 01, 2021 at 11:54:27PM +0500, Nikita Zlobin wrote: ..... > > > 2. Gfxterm (graphics output server). > > > > What's great in TUI apps - probably, that they don't do graphical > > drawing in their own. They just send & receive text. Same convept > > could be used for gui. Perhaps, even redraws could be scheduled at > > this level too - gfx term would redraw only changed regions, taking > > this burden from gui. > > > > Well, I know that X11 has own X drawing utilities. But it's just too > > outdated. For example - X bitmap creation, X draw API vs cairo. > > Cairo wins by accuracy, result from X api looks too coarse > > comparing to that. I discovered this while contributing to dunst > > notification daemon. Originally it used Xshape'd opaque RGB format. > > Now it involves Xshape when no compositor available (though I would > > prefer both, because when picom blur is used, it blurs even fully > > transparent areas if not shaped out). Dunst commit: > > 0e35c6acb0c110a4ab00a560ff15f3e2c85c5f4c. > > > > Btw, what about wayland? Can it have place in suckless paradigm or > > it's rather rockless? In my vision, serving a compositing manager > > is rather essential for window system, which does the final output. > > > > After all, compositing could have different modes - it could be full > > (as in compton, compiz), pseudo-like (can't find better name, when > > only wallpaper image is used for background, ignoring underlying > > windows) or off. > > > > Also would like to note one problem, affecting most of graphics > > drawing systems. I noticed, that for correct result - shaping alpha > > blending must be done separately from transparency alpha. Applying > > both before compositing with rest - primary (probably only one) > > reason for various artifacts. Ideally - each pixels must first > > undergo color mixing (for transparent layers). Also in dunst: commit > > 9833fbba1f6259de40828b213090eb9908861047. > > > > 3. GUI server. > > > > GUI display also could be done in unified way. Applications would > > just pass structure - of course, not in xml, but in more optimal > > way (this leads to another idea - unified language/protocol system). > > Theoretically it would allow (if someone has time and motivation) to > > write scripts, directly printing data to necessary channel (well, > > for shell script it would be at least fifo) and read back. > > > > ltk: git://lumidify.org/ltk.git At least by description - this is closest: Socket-based GUI for X11 (WIP) > swk (unmaintained): https://oldgit.suckless.org/swk/log.html From first look it's just another gui toolkit. > dialog: https://invisible-island.net/dialog/ > zenity: https://help.gnome.org/users/zenity/ Exactly not zenity, at least for now: --listen option is only for notification mode. > > > 4. Unified (minimal) system to easy language & protocol support. > > > > - each language should have user-readable and compiled > > representation > > - unified interface to (de)compile data, be it in API or cmd > > utilities > > - accept both files and streams for processing (auto stream mode if > > file is fifo). > > > > Maybe qbe compiler backend: https://c9x.me/compile/ Could be that. Site is unavailable, so I found it only at github: https://github.com/8l/qbe Of course, I did not mean to reinvent existing things like yacc/bison, rather complement them.