On Thu, Jul 01, 2021 at 11:54:27PM +0500, Nikita Zlobin wrote: > Hello. > I had some ideas for several years, but never tried to discuss them due > to nothing similar was ever in use. I like suckless direction, though I > would also seek to use same concepts (those I already know) to boost > effectives and usefulness for regular-user-oriented configs as well > > As for 'config' word meaning - I leave maximum range if possible > meanings, with at least these: > 1 - desktop configuration, > 2 - any utilities combination (most likely organized to pipeline) for > case-specific solution, probably onetime. > > === Ideas === > > 1. Versatile communication interface > > Applications, requiring IPC or other under-hood communication kind, > could just get channel and use it. Burden channel maintainance should > be done by separate system or lib. Variants: > - shared memory (via API only) > - fifo, socket, etc (via everything, including scripts) >
Theres imsg (see OpenBSD source-tree or tmux), POSIX message queue, 9p. > 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 swk (unmaintained): https://oldgit.suckless.org/swk/log.html dialog: https://invisible-island.net/dialog/ zenity: https://help.gnome.org/users/zenity/ > 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/ -- Kind regards, Hiltjo
