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
Received on Thu Jul 01 2021 - 23:17:33 CEST