LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sat, 1 Feb 2014 15:02:33 -0500
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Message-ID:
In-Reply-To:
<[log in to unmask]> (Paulo Roberto Massa Cereda's message of "Wed, 29 Jan 2014 09:13:40 -0200")
Content-Type:
multipart/mixed; boundary="=-=-="
From:
Sean Allred <[log in to unmask]>
Parts/Attachments:
text/plain (3964 bytes) , interface.png (25 kB)
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
Frank above).

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

> 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
key--value interface.

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
user roles.

> 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

    http://www.github.com/vermiculus/gui4l3

Feel free to correct any misconceptions I might have about LaTeX3 :)

-- 
Thanks,
Sean



ATOM RSS1 RSS2