Paulo Roberto Massa Cereda <[log in to unmask]> writes:
> I'm not a fan of GUI's since IMHO you might end up damaging two things
> at once: your presentation layer and the underlying language. Anyway,
> I'm probably biased :) but I'm concerned on how the mapping between
> them would happen. To quote two principles of compiler design that I
> think important to the discussion:
> 1. a compiler must preserve the meaning of the program to be compiled.
> 2. a compiler must somehow enhance the program to be compiled.
> A direct mapping from a graphical model to a code implementation is
> very interesting, but we might end up with a poor generated code, and
> this might compromise the whole project IMHO. :(
I think it's important for me to say that I don't think this should (or
could) be a compiler. We know that TeX (and by extension, LaTeX) was
never *meant* to be Turing-complete; LaTeX was meant to be a *markup*
language. This doesn't preclude it from being compiled---more
importantly, it doesn't necessitate it. It is not necessary for a
markup language to be compiled; it can be edited in-place. I had in
mind something conceptually similar "Batch Commander" (linked to by
In summary, I wouldn't so much call it a 'graphical model' as a
'graphical viewmodel'. There would be an bijective mapping between
between the syntax `xtemplate` / whatever eventually takes its place and
the graphical viewer and editor. All template implementation and
code-behind would still be done by a loving hand.
> I'm talking from a bad experience I had with biblatex styles and a GUI
> I wrote. Everything was fine at first, but suddenly, the generated
> code was a delicious but indigestible spaghetti.
I guess you could say your software solution was gluten-intolerant. :)
I'm not familiar with BibLaTeX style definitions so I can't say for
certain, but I'd imagine it's a far more complex syntax than that which
`xtemplate` promises. All that I would imagine needing to happen in
the current case is a simple, intelligently displayed key--value
> Of course, in a perfect world we would have an optimization box (aka
> the EG box :)) that would enhance the model and provide the "right"
> way of doing things. That's why I'd favour templating instead of a
> full GUI thingy like LyX. :)
My current idea would *only ever work* when things were done the 'right'
way. No author of a LaTeX document should ever be providing anything
more than markup and the occasional specific instruction through a
In a lot of ways this is what LyX does, but LyX does it through a
distinctly separate language and package-management system that is
kludgey and difficult to work with.
> I have a couple of systems that export things to LaTeX and the way I
> do this is via templating. Roughly speaking, you merge data with model
> and get the document. Along these lines, we could have a n-layered
> templating framework, with one template for each layer of "data" and
> with a well-established interface between them.
> Maybe a hybrid tool that allows users fill the blanks while relying on
> templates is a good way of making people more close to L3: customers
> get what they want and a good code is available. :)
Roughly speaking, that's the same idea I had, except there would be a
finite (n<5) number of layers---a direct mapping of LaTeX3 layers and
> But that's just my humble opinion. :) Maybe if you could provide some
> sketches on what you were thinking, we could work on them.
Your humble opinion is, as always, valuable and cherished. I've
attached a PNG of what I had imagined such a system to look like. I'm
still reading through and learning about LaTeX3 layers and the state of
the overall project in general, but this is a realization of what I
understand LaTeX3 to mean. The Balsamiq source (the same tech UI.SE
uses) is available at
Feel free to correct any misconceptions I might have about LaTeX3 :)