[dev] Possible ideas for suckless project

From: Nikita Zlobin <nick87720z_AT_gmail.com>
Date: Thu, 1 Jul 2021 23:54:27 +0500

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)

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.

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).
Received on Thu Jul 01 2021 - 20:54:27 CEST