Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id s12LGspj030712 for ; Sun, 2 Feb 2014 22:16:55 +0100 Received: from relay2.uni-heidelberg.de ([129.206.210.211]) by mx-ha.gmx.net (mxgmx010) with ESMTPS (Nemesis) id 0Lfol8-1VTXnm1prW-00pMsM for ; Sun, 02 Feb 2014 22:16:48 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s12LE4Ri028803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Feb 2014 22:14:04 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s126u9p8006427; Sun, 2 Feb 2014 22:14:03 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 10686774 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 2 Feb 2014 22:14:03 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s12LE3NB022334 for ; Sun, 2 Feb 2014 22:14:03 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s12LDrhF028749 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 2 Feb 2014 22:13:55 +0100 Received: from mittelbach-online.de (pD9FE2382.dip0.t-ipconnect.de [217.254.35.130]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MSJ5v-1VhEz406x9-00TTob; Sun, 02 Feb 2014 22:13:53 +0100 Received: from [192.168.123.105] (falco [192.168.123.105]) (Authenticated sender: frank) by mittelbach-online.de (Postfix) with ESMTPSA id E8212280C74 for ; Sun, 2 Feb 2014 21:57:58 +0100 (CET) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 References: <52E8E264.4010800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: E8212280C74.A2E91 X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: frank.mittelbach@latex-project.org X-Spam-Status: No X-Provags-ID: V02:K0:5JhXNFnh+UaMzUg+DLSMgnjya31Npwe2Sv6jsYxe66c mp4YPjRoVSZl1fN+Efl+OTgKo1jnm+Xau7/Cg5CnW5omOZmpXb cm+1eVxlMTMk+KjVwUgc3jKJle4ygw6gwgXwpuJcL2EqVyNH7p NDTP5eumeqRLe/vnFeBlzJ1iO2/Ne9yMmehkYz4EMFK4ffotGm vhtv+aT+Ju+k32sV6sDcI4kCHMIZ6r+9VjUox9/wVlUzmAPJ/g FNaVbiXmc4oZThpXLY/8ZfBLtECopZuWeOhX4o67l9jIxpDNVd eGuQrPjPfgQ8SxVsgVwgs2I+QINon+YgZNUJJekMDhUuFKZ+1f TAGYkrRqJskXn1VgO8ErI3VT/DYIvzGzdtroyjslxv4mzaOqRp 5E8827NDRrutw== Message-ID: <52EEB4F6.9010800@latex-project.org> Date: Sun, 2 Feb 2014 22:13:26 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Feasibility of GUIs for authors and class designers in LaTeX3 To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <52E8E264.4010800@gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:KyyqMjH8fgw=:9CTTJ2Wok4XEsm6I6vKBn6vX2s PCC6eXkXA+6S7J2lgK3uJ2abyqIja3zwTlvYD3UzOlHm8rlCyFYHmheF3tL/dRMh91OWVv+Xn qYzeS35a3aHWbo/EMwbsOCWLOTfEBUqPzbIrzqIlll9Kv7WxdJREmx4GM7n0g57Z9xrsQ9lMy DpdrOgaFqGbHLx8tK9v1hlnDVO0mgkmZAqa0GPI+JQHi3+l/Q0TJ8jEqs0hYRcd7rAaJWV8te hhEoUMT/XjI1FVOeHNCWgHSRzNnjEpHYhQAcOjcbS3LliS6zCk4gmlYM9wG9CtnnJoIoh/lBP 7/o/H8jOFhKtnhhvSAndnGZxeD4RGtEKuuJyUjuY1XCjV70mMQY3lp0OcqDOOqoP7ssRmtZl4 PzSqqtxN0wOMhXlUO40Ii/wQyL7Dahcm72BF0TBr21RUcoWEtAb3S41R4vLowVKVdbmpNC6L2 TsGSBJK8hZjOJBkC31U9dp1TiQ5tBj40is0Jf6UZcVE7iQfGkISnEikUQcqdtnNseld6I8Vuz fte26K/eFkyN5qYOcjRZLJpRVXmMQv3HIlKVBn6Y2gYjfLiCJRQ6gw8jJ2zXZ1bjPm9SHTDUJ DQFre8EqQNT9hd9vV+oKy0qoDslG3EEsIjQMoQFmCCqn7/ZQnN5hgdxYBnSLDOj81/2RGwacw Rb748/IwVGkG/55lHrNGPY7TlKo1XTj0o/QRCkjO6aUm+/dP23BSbA5I3gVK1pkA40i5Ej5rT HOvHQ6bwltZ7RrdH7srgF9UYeLDXyRbNplD3PbeAnS7Sd8cU5nsuVzLR2OBSoLVoQUHbhkZ9i OELWJoGARYV3CCqhEUiMEdLwG2e4EPpqBQaVMxTc3UF5wju+N7oXbENop1e67lLVnDUfJo25R C2ygSwGJJub8ReOfOLkDezIk6HOTZKkxGcEr60v6Cyphx7xSO7T1xAAZMzL5PQbHoT9h4m9An Y66Vf61qhdFVoErz74Ivsz/K22ZgP3Uidvw5nJex6yWgYHccInk8d3wKhOwFC41pKOVjdhHU+ 7A1/tQTa4NUHRbkenkhaOxbaqaDGxU0W5HPplp4dxVbSpArrB0zUjCQH1MDdjEx8Jjg995usL Iv2HfoSSUtET/IUxEW8+MPygAcnycDFacrddlEiqwU/l0elwOdLcnBK5azG/de3IPOVzhZMfA XzG+B8BMtRlQe3OirmHLprea7aPIhpJWhILcyxu0FHi47ZUpH1K+Ag0jqDN4CJCzwrhYs8KvA HHhdnyz3s60MtB0I+ExzVb0fHpnAlrLFBsmTp7B+Xym3oRGQMuArXS0+BEEo6kbRd5HFvHeuD fctW7EOff1fdaLWyz6f6c0yWK5Gz/F1y7Y+U7IqloL42uW25dy+73rToXAzmQho1KgySerMUf 0qbC1s/PpITfZ0Ft2jKmAf1uswjE1nwG5oF8xsN76PUnZ98it3f88VnQL5Z X-UI-Loop:V01:4V11DVt36SQ=:Tx/8vC69PuONtE/iCKEBtB756ri3WOEJO4Kpvqp4sCo= Status: R X-Status: X-Keywords: X-UID: 7325 Hi Paulo, > 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 you have misinterpreted Sean's intention (or perhaps I have). In any case I wasn't speaking about a GUI that generates LaTeX document code, all I was talking about was a graphical representation of underlying templates so not really something fancy. If you think about an independent graphical model that you manipulate with the cursor (or some other tool and that then magically turns your action into code, then I agree it will probably start out nice but eventually you will end up with very bad internal code once things get more complex and you need to cater for all the stuff you originally haven't foreseen. Take headings for example, there are million ways to specify and manipulate portions and there is (imho) no way that a GUI could interpret graphical manipulations and turn them into "correct" code. This is why I think a better way is to allow for exchangeable templates that implement a certain document element but may have different graphical features and manipulation possibilities. For me a Designer GUI would then not much more than an easy way to manage such templates, select them and manipulate their bells and whistles. Such a GUI could be part of a system like LyX but it doesn't have to. It would also be possible to nicely combine it with (nearly) instantaneous realization where a given (or produced) test document is compiled and changes being presented more or less directly after they are done > 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. :) would like to see what you have done in this space but from what I gather it isn't so much different from what I have in mind. > But that's just my humble opinion. :) Maybe if you could provide some > sketches on what you were thinking, we could work on them. that would be a great idea :-) ... and I see Sean already come up with some mockups frank