Karsten Heymann wrote:

> On Wed, 2 Jun 2004 11:01:24 +0200
> Gour <[EMAIL PROTECTED]> wrote:
> 
>> Is there any reason why wxWidgets toolkit is (somehow) avoided?
> 
> Well, I think someone would have to do it :)
> 
>> It's not that I'm pushing it, but, imho, it looks like a mature
>> multi-platform toolkit with a fair licence.
> 
> The more "natural" Toolkit for LyX would be FLTK I think, because it
> seems to be quite close to xforms. But that would have to be done as
> well...

I don't think that is true any longer. The LyX core sees absolutely 
nothing of the GUI toolkit. All toolits are, therefore, equal.

Development in the 1.3.x cycle concentrated on achieving 
GUI-independence and a fully functional port to the Qt toolkit. 
Almost everybody posting questions to the lyx-users list says that 
they're using the Qt frontend, so clearly the effort of porting to Qt 
was worthwhile. The effort of achieving GUI-indenpendence was also 
worthwhile because it removed a vast amount of spaghetti from the LyX 
kernel.

Development in the 1.4.x cycle has concentrated on cleaning up the 
LyX kernel itself. None of the core developers have been particularly 
interested in contributing to the gtk frontend. That's probably 
because they felt that having a gtk port was less important than 
having a clean and maintainable kernel. I think that we've gone a 
long way to achieving that goal. In turn, it's made it easier to add 
the new features that the users will see in LyX 1.4.

It makes sense to maintain two frontends, because that keeps us 
'honest' to the original goal of GUI-indenpendence: clean, generic 
code in the core.

The Qt frontend is already more powerful than the XForms one, with 
'proper' support for bi-directional languages such as Hebrew. 
Moreover, the Qt version of CJK-LyX is both cleaner and more 
sophisticated. I suspect that the exciting development in the 1.5.x 
cycle will be full unicode support. When that happens, merging of 
CJK-LyX into LyX becomes practical.

So, the XForms frontend will probably become the poor relation to the 
Qt frontend. I don't think that we have sufficient man power or 
motivation to change that. Instead, I think that the interest in 
supporting a gtk frontend will increase. The gtk toolkit has all the 
bells and whistles that we'll need in the future and, like Qt, is 
actively developed. Moreover, it's adoption will ease the adoption of 
LyX by Win32 users.

So, should we be interested in supporting a gtk frontend in the 1.5.x 
cycle? IMO, yes. If development goes the way I've outlined above, 
then it may also make sense to consider 'retiring' the XForms 
frontend.

Should we be interested in supporting a frontend based on Yet Another 
Toolkit? IMO, no. We should not waste our effort carelessly. The goal 
should be a more powerful tool accessible to more people.

-- 
Angus

Reply via email to