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
pgp93EfhbYpBs.pgp
Description: PGP signature