On Sat, May 14, 2005 at 02:11:21PM +0100, John Levon wrote:
> On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote:
> 
> > OK, but that tells us also something about the current state of
> > incompleteness of GUI-I. Ideally, the front ends should only define a
> > set of primitives that the rest of LyX then uses. I am thinking of a
> > termcap type parametrization thingy, but graphically.
> 
> I sincerely hope you're not bringing up the idea I think you might be.
> No, 'frontends provide method for drawing combos, everything else is
> GUII' is not where we want to be.

No, that is out. Too late now, if it were ever possible. 
 
> > can certainly get farther than we are now. In my understanding there is 
> > _no reason at all_ why _any_ translatable strings should be front end 
> 
> This is not true, actually. Different platforms have all sorts of
> different rules on how we present data. Historically, the biggest
> difference has been that xforms remains close to 'classic' LyX, whereas
> in Qt we were free to use higher-order views, and experiment with the
> UI. One example is that we still differ on the rules used for tooltips
> between the two frontends.

Yes... but then we should try to move them closer together again. Yes,
some differences will remain. We should certainly have only one
translatable string copy -- located in the common part outside the front
ends -- for every message we send out, with few motivated exceptions.
For some of the dialogs this has been done.

> Gnome will again have different rules. I'm all for Michael's work in
> reducing translator load (so far), but this will not extend to
> the point where lowest-common-denominator UIs are the only option.
> 
> I don't see an architectural approach to reducing this load; what do you
> have in mind?

The above. I believe the _translator_ load per front end can be brought 
down to close to zero; as for the _coding_ load caused by the ongoing
evolution of the LyX core code, that of course will never be zero short
of a pure termcap-style primitives architecture.

> Multiple frontends has never been a serious portion of the maintainer
> load; it's generally been (originally) the hulking mass of old kernel
> code; currently it's the serious stability problems of the new code.

Now there I agree. Which is why I think we should not just "drop" any
front ends. We need at least two more or less useable ones to keep GUI-I
alive, now that we have it.

I expect that in 1.5, we can combine much of the work of getting xforms to
behave more similarly to qt (i.e., more modern) with moving stuff out of 
front-end specific code into common code.

> regards,
> john

Regards Martin

Attachment: pgp93EfhbYpBs.pgp
Description: PGP signature

Reply via email to