Re: GUI builder using troff pic

Hi Bento,

for the programming background of your idea, I humbly suggest you have a 
look at Metafont, Donald Knuth's font description language created by 
him for the TeX system, as a source of conceptual inspiration.

Besides the more conventional way of assigning values to variables, 
Metafont offers a second mechanism which may be helpful for your project 
as it contains an equation solver. See page 14 of this tutorial:

http://metafont.tutorial.free.fr/downloads/mftut.pdf

Your ideas outlined below immediately prompted me to think of Metafont. 
The linear equation solver is also part of the MetaPost programming 
language; Metafont is open source, the source file is well documented. 
The code itself is written in a well-readable meta-language.

Unfortunately I stopped programming in Metafont nearly two decades ago 
and am currently engulfed in a gyre of work, so I cannot offer more 
immediate support; I only can wish you

"Good luck on your mission!"

Best,

Oliver.



On 29/11/2025 05:10, Bento Borges Schirmer wrote:
> Hey list,
>
> I really really really really liked pic.
>
> This vacation I will create a small tool that reads a fraction of pic
> syntax, and turns it into C code, that can be compiled to draw GUIs in
> a graphical program.
>
> My idea is to have a fully imperative GUI builder.
>
> So, for example. A windowed app, the window is resizable. As it
> shrinks, elements cease to fit inside, so you need to replace them
> with a smaller version, or collapse them entirely inside a menu. I
> want this to happen fully imperatively, like, there is a condition
> that tests if things fit or not, and what will be drawn next. Another
> case would be layouting a grid, I want the layout to be decided
> imperatively using a linear or binary search. All of this exposed to
> the programmer, no abstraction.
>
> I want it to contrast with current declarative means to create GUIs.
> You see, I have zero experience working as mobile or web developer, so
> I don't have experience to back up any claims; I can't say from
> experience that such and such is bad or good. But I get the feeling
> that the abstraction provided, you have to fight with it a lot, like,
> translate what you really want "position this box relative to this
> box" with the hierarchy of elements it imposes, and whatever automatic
> means it has.
>
> The few times I tried to build GUIs, I wanted to position stuff in
> certain ways, like in the bottom of the window, and I'd be told "just
> calculate everything yourself then". That sucks, because the solution
> is not really helping at all. pic at least have several means to
> specify things relative to each other, and group things arbitrarily,
> so there is that.
>
> But the idea is to extend the pic syntax with clauses to "give up" a
> block of graphics, and a "eval" that will just calculate bounds
> without drawing, and some other that "branches" several attempts and
> only draws some, but also memorizes other results somehow, and there
> is also scrolling to deal with.
>
> The point is. I will implement a basic fraction of pic, if it works, I
> will try to expand more. Or maybe I misunderstood everything! I also
> don't have experience with GUI development, so I may also
> misunderstand the "real" challenges current technology really solves,
> like uuuuh... I don't know?
>
> I've been using groff heavily to produce my thesis text and slides,
> after my semester ends, I have plenty to discuss, lots in my mind
> right now.
>
> Best regards,
> Bento
>
-- 
Dr. Oliver Corff
mailto:[email protected]