texmacs-dev
[Top][All Lists]
Advanced

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

[Texmacs-dev] Re: Compiling TexMacs on OSX


From: Henri Lesourd
Subject: [Texmacs-dev] Re: Compiling TexMacs on OSX
Date: Mon, 16 Jun 2008 15:34:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Abdelrazak Younes wrote:

Henri Lesourd wrote:
Currently, there are only two ports (Qt and Cocoa), with two
maintainers (Me and Massimo), thus it seems manageable.


At this point, yes, I agree :-)
But I am sure that by fully switching to Qt you'll be able to attract new developers.

The goal was rather to design a small, platform-independent
API, in such a way that at some point, you *don't* need to
extend it anymore, besides the possibility of extending the
set of available widgets by means of trivially wrapping them.

On the other hand, some of the widgets we implement can be
used for building other widgets, thus another part of the
extensions is in defining composite widgets on top of the
low-level encapsulation of the underlying GUI.


It could also be that our encapsulation is done in such a
way that it turns maintaining to an easy task (although I'm
not 100% sure about that).


As I said in another message, encapsulation of a GUI API is not a very good idea IMHO. IIUC Texmacs have some kind of embedded dialogs that are drawn directly in the work area. Of course, those should stay as is, managed by the core directly; the frontend should not know about them. But in the other way, the core should not know about higher level dialogs programmed with your GUI toolkit of choice.

This is not the only possible problematic in designing
a GUI API.

The underlying problem with this is that, true enough,
you turn the task of designing a portable toolkit to
something very easy if you implement all the widgets
yourself, and support only a very low-level portable
API (basically, drawing and low-level events).

The drawback of this approach is that you don't
enjoy a native look and feel anymore, or either,
if you want to do it on top of this kind of
design, then it's a lot of work (the kind of
work you *don't* want to do, in fact) to design
the natively looking skins and the "stylesheet"
language you will need for this purpose.


I was thinking about adding Texmacs format as another additional backend along the current LateX and Docbook backends. This could bring real-time pre-visualisation to LyX using Texmacs side by side :-) We cannot do that kind of things with LateX as the compilation is much too long. Just an idea...

You could do it, although an unsolveable problem
in TeXmacs is that it *cannot* import TeX.

Thus each LaTeX style file must be reimplemented
from scratch in the TeXmacs stylesheet language,
and there are things you can build by means of
hacks in LaTeX (e.g.: PsTricks) that are absolutely
infeasible in TeXmacs (except if you decide to
extend the core C++ rendering engine, which is
much harder than devising a way to hack the output
thru TeX by means of inlining the right kind of
Postscript).


(although
time, which is the most important resource, is currently
missing).


Definitely... most probably the reason why the idea above will probably not see the light.

There are other reasons, a chief one being
than the design of TeXmacs is 100% clean,
but hacker-unfriendly, while the design
of LaTeX is in fact crap, but hacker-friendly.

Thus lots of resources would be needed to
really bridge that gap.




reply via email to

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