On 9/14/18 2:38 AM, Baris Erkus wrote: > If the intention is more like a complete WYSIWYG software package (or > bundle) allowing users to produce documents right after installation > without much hassle of Tex and other setups and preventing them from > dealing with low-level Latex programming, it would be more reasonable > to develop LyX as a bundle/package of LyX Frontend+TeX system+misc > components. This would make the bundle more predictable and manageable > if the components of the package are package-specific and they are > developed specifically for the package. In this case, the TeX system > should be customized by the LyX developers and should not be allowed > to be updated by a third party software. This is the approach taken by > Scientific Workplace and Bakoma, I guess. > > If the intention is develop only a powerful frontend that allows users > to juggle around the TeX system, to do their own customization, allow > different TeX systems to be used (and let the TeX developers to do > job of developing TeX systems) and even maybe allow users install > their own addons and functions to LyX, then LyX should have a module > that can communicate with different TeX systems efficiently and should > be immune to changes and updates in the TeX system. > > In my opinion, it is just not feasible/meaningful to achieve these two > different-and conflicting-by-nature intentions at the same time.
Unfortunately, my own sense is that it is of LyX's essence to straddle that line. On the one hand, we do strive to ease the learning curve for people who ulimately need or want to know LaTeX. (Many of us on the development team are like that.) But, on the other hand, we also hope to make LyX usable by folks who know nothing of LaTeX. We have had important developers (e.g. Abdel Younes) who knew very little LaTeX. I've got many students who use LyX who are in the same boat. On a different note: It is worth remembering that LyX does not just (directly) export TeX. It also exports DocBook and XHTML, and the latter might long-term be more important due to its compatibilty with ebook formats. If I had more time---I wrote the XHTML export code---I'd do a lot more in that direction. But even though I don't, it would not be difficult for people who cared about such functionality to do that work: It has more to do with time and experimentation (e.g., what CSS works and what does not) than it does to do with complex coding in C++/Qt. Anyone who cares about that, please let me know, and I can direct you to a lot of bugs that need attention. So, as so often with FOSS (Free and Open Source Software) projects, the issues fundamentallly concern people power. We *know* what LyX's weakenesses are, but we do not have the people-hours to address all of them. All of us who work on LyX are volunteers, so we generally work on what matters to us---but there are about half as many of us as there were when I started, around 2006. And of course we are 'advanced' users. Riki
