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