In Thu, 1 Jul 2021 23:17:33 +0200
Hiltjo Posthuma <hiltjo_AT_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.
Received on Fri Jul 02 2021 - 14:20:30 CEST