On Monday 28 May 2001 03:34, Lars Gullik Bjønnes wrote:
> George De Bruin <[EMAIL PROTECTED]> writes:
> | Now, I see from a development point where it will be necessary to focus
> | on one or two languages for the initial implementation / testing. But,
> | as soon as that is done I think the support should be expanded to at
> | least six or more languages to avoid any perception of bias.
>
> Perfect way to split development effort and get nothing done...
Lars, I don't see it this way. Part of the reason is that I don't stay
within the box of looking at the development, or the development team as
being static. If the resources of the team were limited to the current
group, I would say you were correct.
However, as I mentioned in my message to Baruch (which I've just posted), why
not make it a prerequisite that for each language implemented there be
someone (preferably outside the core development team) to implement and
maintain each language.
> Even:
> | This is the same as the concept of GUI independence.
>
> I do not quite agree, as said the scripting language would be used to
> implement _core_ functionality in LyX.
Okay, I understand your point here. However, think of this from the users
side: what do they see when they start LyX: the GUI. To the average user,
the GUI is the program.
> IMO there should be _one_
> official scripting language that would need to have to be able to run
> lyx. The scripting language would preferably we distributed with LyX.
> _If_ someone would then like to use a different language with LyX that
> could easily be done by having a module for the official scripting
> language.
We get to disagree on this one. :) If we go with one language, then we run
into the current perception that is true with the GUI. As it stands now
(especially when you look at the website) LyX looks as if it is biased
towards using XForms, and that very little work is being done on the GUI
independence. Add to that the responses on the KLyX mailing list to
inquiries about it's functions (ie, use LyX instead) and you compound this
impression. You and I may know that isn't the case, but what else is a user
going to think?
> .... btw If we are not going to use the scripting language for _core_
> functions, then we can just do with the lyx server as it is now.
I'd say as a starting point it would be a good idea to allow the LyX server
commands to be exported to a library that can be used in scripting languages.
But eventually, it needs to include some way of querying and setting internal
states in LyX.
(Just my opinion...:)
--
George J. De Bruin
Check Out 0l0rin's New Age compositions at http://mp3.com/0l0rin
0l0rin's latest recording "Collection" is available now!
