Re: [Texmacs-dev] TeXmacs gwt front-end

[Henri Lesourd]

Amir Michail wrote:

> Well, at least mathml with its fonts could provide most of the symbols
> that you need for math mode.
>
> If you want to use the TeXmacs typesetter, then yes, you would not
> take advantage of the browser's mathml typesetting.
The problem is that you want to reuse the TeXmacs edition
process, and this latter one doesn't work without the TeXmacs
typesetter.


> However, there's probably a way to have low-level control over
> character positioning via css.
Yes, but is unuseable, it's way too inefficient : these kinds
of operations are the ones that must be fast (because of
how the editor operates), and you would need to reload
the whole page for this (or operate via DOM, but then
you go to other problems).

This is what happens when you are in front of an inversion
of abstraction, namely, the available API is too opaque,
and removes control on the low level operations. As a
result of that, we are left to the crappy strategy of finding
a way to rebuild these elementary operations by means
of the complex ones that are available, and even when
it is possible, we loose anyway the speed.


> > > Also, TeXmacs is quite usable with nx and broadband, so maybe
> > > something could be done with ajax as well.
> > >
> > It's true that something could perhaps be done. But
> > whatever these Google people say, I know pretty well
> > that the BIG problem with Ajax, Web 2.0, and the like
> > is that as a whole, it is absolutely not portable at all : you
> > want to do one application, but you still need to do as much
> > hacks as there are different browsers where you want your
> > application being able to run.
>
>
> The whole point of gwt is to provide portability across browsers. The
> hacks go into gwt, not the application. It's not perfect, but it is
> improving all the time in that regard.
It's reasonable to suppose that in some years from now,
portability will be achieved (although still we do a bet,
in this respect...).

But it's a long, long way till it becomes as fast as a thin
layer over X-Windows. As a matter of fact, if you can't
compile your JavaScript and run the corresponding executable
file inside your browser, it will *never* happen that it gives
us the computing power we need. As for me, I'm not aware
of such plans of implementing JavaScript compilation in
the main browsers. But it's a classical thing to do, so browser
implementors will unavoidably think about that, at some
point. But when ?


> It may never be solved (particularly as <censored> may not want it to
> be solved), but gwt might be close enough.
This is in effect one of the important reasons why I
see a problem with Ajax, Web 2.0, etc. If you put aside
the problem of the overbloating of the (thousands) of
standards it is supposed to use when completed, you
see that anyway, such a thing could radically simplify
computer programming : basically, you would come
to program everything in JavaScript, and you would
have lots of pre-programmed, standard stuff in lots
of libraries available for free, and you could do local
apps, and distributed apps, as well.

For sure, there is a lot of business in the domain
of software tools, and even operating systems
that would become completely obsolete and
be wiped out if such a thing happens.

Thus for sure, you are 100% right : one can safely
bet that a fair amount of players in the so-called
software "industry" have a very, very, very strong
interest in maintaining things complex, incompatible,
and non inter-operable the way they are currently...