Andre Poenitz wrote:
> On Mon, May 16, 2005 at 01:03:42PM +0100, John Levon wrote:
>> Or we can just provide a simple interface from lyxrc that uses Qt if the
>> frontend has something. This is just not difficult to do.
>>
>> > > Furthermore, they encourage commingling of frontend code with logic
>> > > code, which is just a bad idea.
>> >
>> > Well, Qt 4.0 uses MVC as well.
>>
>> Um, we're not ready to use Qt 4, and even if we were, and knowing Qt as
>> well as I do, I expect its attempt at MVC is still going to be "our way
>> or the highway".
>
> They seemingly learned a lesson or two. Qt 4 is conceptionally much
> cleaner than Qt 3 and older.
>
>> > > Do you really think the GUI logic was clearer when xforms lived in
>> > > src/ instead of src/frontends/qt2/ ?
>> >
>> > No. And I am not proposing to merge them again. BUt I am against e.g.
>> > having MenuBackend.C & Co.
>>
>> What, because of the huge maintenance burden? You seem to be the only
>> one here who thinks this stuff is a problem, and I honestly don't
>> understand why. Especially since, AFAIK, most of the work you've done
>> has been on mathed and the LyX core, and not much on GUII or the
>> frontends.
>
> Indeed. I havne't done any. Mainly because I found it all the time too
> difficult to come up with a new dialog quickly.
>
>> Surely you agree that the hard, time consuming stuff is in the core, and
>> it always has been?
>
> Not too sure. Guess why mathed has several dozen insets but only one
> major dialog which has been there all the time. Certainly not because
> these insets don't need a dialog but rather because a new simple inset
> is hacked together in ten minutes, but a new dialog (the LyX way) is
> not.
Oh, cobblers! You are reinventing history to suit yourself.
If I remember correctly, we tried to use the existing table dialog for
mathed tables and discovered two problems:
1. Information is transfered to/from the frontends using some poor man's
serialization that I invented. (Based, I might add on the existing LyX
file format.) So, you'd need to add some serialization/deserialization
stuff to mathed. (Trivial, given that mathed can parse such strings.) Or,
alternatively, rework this information transfer to/from the frontends.
Given that we have effectively got a
Dispatch(string const &);
interface to the kernel from 'outside', that might be a little harder.]
2. Getting info into the kernel from the frontend was easy enough. In other
words, we achieved 1., above. However, 'dispatching' it correctly was a
PITA because inset unification was not complete. Nownetheless, we also
achieved this for at least the RefInset or somesuch.
Neither of these have anything to do with how the frontend is coded up.
They have everything to do with how the frontend interacts with the core.
I have no problem at all with your desire to make LyX a Qt-only app, but
this particular argument is entirely specious.
Angus
