[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Henri Lesourd
Subject: Re: [Texmacs-dev] TeXmacs gwt front-end
Date: Fri, 01 Dec 2006 23:49:36 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821

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

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...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]