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


Reply via email to