Charles de Miramon wrote: > Rich Shepard wrote: > > >> However, when I press ctrl-f I see a dialog box that has two text >> entry >> widgets (for search string and replace string) and four buttons: "Find >> next", "Replace", "Replace all" and "Close". I've used it extensively. >> Works fine. >> > > I was not talking of ctrl-f but of a powerfull search&replace where you > can search "foo" in emphasize style or in language Spanish, or in a > footnote. > > It is feature that has been asked for several years by several people. I > dont want to appear to be whining and complaining. If the LyX developpers > have not added this feature it is, I believe, because it is not easy to > do in the actual framework. > > In KWord (which is not, I agree a perfect or even really functional > Wordprocessor) we have this feature. Not because, KWord has a big > development team (it is indeed less numerous than the LyX team) but > because we use the Qtextdocument class which gives us the possibility for > regexp expressions. Implementing the feature becomes much more easy, > designing the right regexp, building a usable GUI, and pluging it into > the QT API http://doc.trolltech.com/4.0/qtextdocument.html > > Another example of the advantages of basing you application on a rich > framework. I've followed a conference of Lars Knoll, the Trolltech (and > KDE) developer responsible for QTextdocument. In the next version of Qt, > QTextDocument will be fully unicode. He gaves us example how fiendishly > complicated it is to create a interface to enter Unicode text, deleting, > selecting with a mouse for language like Chinese, India, etc. It is a 2 > man/year job. In KWord we get all that for free. > > If LyX was a KDE application, it could used the KScript class that add a > generic scripting engine for an application, reuse the plugin interface > developed for other applications, etc. > > KDE or QT should not be viewed from an user point of view (I like or > dislike KDE/Gnome/Gtk ; it is too heavy, bloated, etc.) but as a > successfull development model. By building a common, rich framework that > goes much further than a set of widgets you mutualize the coding work and > make it possible for application developers to concentrate on their core > business (burning cd, listening to music, interfacing with LateX).
Hi, Charles. I don't think that any of the LyX developers will disagree with you when you say that external libraries can provide us with powerful functionality for minimal cost. However, our own experience has informed the approach we have persued. The original code base had "GUI" code intimately entwined with "core" code. It doesn't really matter whether this "GUI" code is XForms, Qt or GTK, because the primary point is that the result was an unmaintainable mess. Good software is modular. It means that I, a developer, don't have to understand *everything* in the code base to make a change. LyX has become more and more modular over the years. It has also used more and more external libraries. It's just that the libraries we have chosen to use are primarily those of Boost rather than of Qt or of KDE or of GTK. LyX 1.4.x is 30% smaller than LyX 1.3.x, both in terms of executable size and in terms of code that must be maintained by the LyX developers. Nonetheless, it contains more features than LyX 1.3.x. We could not have reached such a position without using external libraries heavily. So, to return to the examples you cite. All of this functionality can be added to LyX. For example, see the Qt version of the CJK-LyX port if you want to see how easy it was to add Far Eastern language support to LyX. They did so by leveraging the power of the Qt library. If there were more LyX developers with more time, then this port could easily be merged back into the official LyX sources. But there aren't, so it hasn't. I repeat Lars' statement, that we are not interested in the lowest common denominator. If one toolkit provides functionality that another toolkit doesn't, then it is still perfectly acceptable to leverage that functionality. It's just that we'll require the "core" code to be insulated from the details. Modular code is good code. I also repeat my other reply to this thread: this is *your* software. If you want it to improve, then the best way forward is to contribute. > Cheers, > Charles -- Angus
