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).
