"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| I was never angry about the KDE port you did. I even considered branching
| with you.
I was never angry about the _port_, I was angry about the lack of
communication!
| Now, the situation is different. I think it is more realistic to switch
| to Qt now, since the political problems have been solved. It is entirely
| realistic to use Qt as the main focus.
I can agree with that, _but_ the GUII work is still needed. We really
really want the "core" of LyX to be separated from the GUI/Desktop.
| In my mind, there is still no doubt that Qt is the technically superior
| architechture, and always was. I'm sure the others agree with this.
My only qualm with Qt is that it is not modern C++, but still, the
toolkit is superb.
| However, we don't control the developers. This argument only works if all
| the active developers agree that a switch to Qt is the right choice. In
| that sense, the situation is no different from two years ago.
One of my most important goal is to finish the GUII... as we have
always said, the most/best supported toolkit after that we most likely
become the default toolkit.
| Personally, I don't actively contribute to LyX any more because I don't
| have the time. I could find limited time to do some work if I was able to
| do it on Windows, because that's what I use nowadays.
but you can if you want to... but probably not with the tools that you
are currently using.
| You would do better by asking why the stable developers feel that it's a
| wrong choice.
|
| I think I can answer some of it for you:
|
| Some developers are not mainly interested in bringing a modern
| application to the users. It's more fun to play around with a
| code, learn C++ some more, clean up the code, and have fun.
| They are not doing this because they need LyX to be better.
| LyX already solves all the problems the main developers have,
| with the exception of some problems that have been attacked
| mainly by Dekel.
|
| At this point, LyX development is less need-driven than ever.
Very true.
We(I) have a lot that we want to do in/with LyX, but we are in no
great rush. We want it done right.
| The developers also do not do the work because they want more
| respect of users. The existing users crowd is already enthuisiatic,
| and it does not matter whether there are 100,000 users or
| 1,000,000 users in this context. If anything, a larger user
| base only brings more anxiety, because then you have more
| responsibility to keep the application stable, and avoid mistakes.
True.
| So, it's much safer to just straddle along with the same old course:
|
| The goal is to build the perfect application, purely from a technical
| point of view. The users of course are important, but in the end, they
| are second. The product is not the application. The product is the code.
| It's the code that has to be perfect. It's not the application.
Hmm... close, but not quite...
| It doesn't matter that it will take a hundred years to achieve the
| perfect GUI independence. What counts is the challenge it is to
| obtain this difficult to achieve goal.
|
| We all know that GUII is hard, and that it will take a long time to
| finish it. But so what? We have all the time in the world. And this
| is the fun part: To master the difficult code.
|
| So, rather than arguing the technical points of whether Qt is the
| better platform or not, you have to do what is much more difficult:
| You have to change the attitude of the developers.
|
| You have to explain that it's fun to increase the user base from 100,000
| to 1,000,000. That there will be other challenging technical problems to
| solve when you do this, rather than the GUI.
| You have to convince the developers that it's more fun to have a user
| focus than a code focus.
Still if the code is "more perfect" it is easier to please users.
| Now, you have a few odds in your favour:
|
| - Qt is politically correct now
But not with regard to Standard C++ and "current best use". Unless
something has radically changed the last year Qt still uses a old C++
style.
| - Allan has recently stepped down as GUII master.
| This implies that the territorial fight is less demanding: You don't
| have to take away this code territory from Allan, since he already
| handed it over to Angus.
|
| - There are many new developers in the LyX team
| It might be possible to "convert" these more easily than the old crowd,
| at in this way change the direction of the boat.
|
| - A large part of the code restructuring towards "everything is an inset"
| is nearer to completion. This will leave a void for the developers
| involved: What great code clean-up project should we attack now?
Oh, I still have some pretty large projects:
- the NEW_INSET code that you mentioned. (lot still missing,
itemize/enumerate is still hardcoded, insetfloat needs some work ...)
- the restructureing of internal storage formats (from implicit home
grown linked list to std::containers) And this is a huge project
since it changes the LyXParagraph and LyXText completely (+ a lot of
other code)
| But the most important thing to remember is respect: You have to respect
| that some have their personal reasons for not wanting to change. I have
| listed some reasons above, but there are certainly others.
I want to add another thing that is _very_ important to rememer:
Communication! Something you have not exactly excelled at. We always
learn about what you are doing or planning later, and you never come
to us and say: "To make a suberb Qt/KDE interface to LyX I need
this..." or "We want to do this, how can we accomplish that... how can
we help".
| Also, you should probably acknowledge that LyX has come a long way in the
| last years. All you have to do is to take a look at the code, and
| remember that the yardstick is code quality, rather than user experience.
I must admit (even if it perhaps is self evident) that I am really
really fond of nice code, and as Asger mentioned, the user interface
is secondary.
Lgb
