[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Re: [TeXmacs] Announcement: TeXmacs.app for MacOS X Ti
Re: [Texmacs-dev] Re: [TeXmacs] Announcement: TeXmacs.app for MacOS X Tiger
Sat, 18 Feb 2006 13:21:13 +0100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
David MENTRE wrote:
[ Follow-up on texmacs-dev@ as it is more a development issue. ]
Juan Pablo Romero <address@hidden> writes:
[ Joris: ]
For the new graphics mode, Henri and I are indeed considering changing
the underlying libraries. Cairo and OpenGL are both good candidates.
Cairo is just a drawing library and does not have widget with native
look and feel of the platform.
No, but (I know that not everybody will agree with this ;-), the native
look & feel for the platform is less important that the functionality
of the widgets themselves.
An important issue related to that is that if we choose a widget lib :
(1) Portability can become a problem ;
(2) Worse, there are very useful things that are (and will) NOT (be)
provided by any widget set (an important one being having LaTeX
output in the menus).
Thus I have no definitive opinion on this, but it seems to me that
the alternative idea of expanding the current TeXmacs widget set
could be considered as an option (that certainly raises other problems).
OpenGL has the same issues as Cairo and moreover does not run on all
platforms (think PDA and broken graphic card drivers).
The two are different : Cairo is built on some other lib (OpenGL,
probably), and is quite convenient, but not completely stable now.
As far as portability is concerned, OpenGL is the most portable
and *standard* 3D lib that exists. In particular, it works
under Linux *and* under Windows.
For PDAs and broken graphics card drivers, a specific solution
should be envisioned, anyway (PDAs ==> probably something
specific ; broken card drivers ==> probably something under
We might also want to opt for an abstract layer (like the current
ps_device) with different implementations.
Would this abstract layer be used for GUI drawing (menus, scroll-bars,
etc.) or only for text and graphic rendering?
The ps_device is only for text and graphic rendering, and it is
working (except perhaps minor currently missing features) exactly
the same under Linux and under Windows.
In fact, it seems to me that there are two different cases to consider:
- the GUI (menus, ...) that should be done using a well known toolkit,
Qt 4 being a very good candidate;
- the drawing area, for text and graphics rendering on different media
(screen, PDF, PS, ...). From what I have eared, Cairo seems to suite
the needs (works on Windows, Unix and MacOS X, abstraction of medium)
but others might have a more knowledged position.
Difficult to be sure now. The thing with Cairo and other
libs like that is that it provides antialiasing, etc.,
which are features that do not exist in the ps_device.
Please, please, please, consider using Qt 4.
With native look and feel on each one of them.
3. Excelent API
4. Very good docs.
Yes, from what I have seen, Qt is well documented.
5. Language bindings
Well, not so sure but anyway TeXmacs and Qt are both using C++.
6. Excelent widget editor
7. Easy integration with kde (wich means kioslaves, etc)
8. Good looks
9. Many people already familiar with it, wich means more workforce.
10. Did I mentioned the widget editor?
In particular, don't underestimate (6) + (9). I'd myself contributed
some code (more dialogs, etc) if only I could use the widget editor
(like, in half an hour you can layout a dialog).
Impressive. It is well known that QT is a f*****g
good environment, otherwise, TrollTech would not
have been able to build their whole business on
that. Thus now that it is free software, it clearly
becomes an extremely attractive choice.
The main problem with all this is that if all the features we need
were clearly part of the OS, then we would only need to design a
clean API to hide the differences between all the OSes, and that
would be a perfect solution (this is exactly for this reason (namely,
the existence of the ps_device layer) that it has been possible to
develop a native version of TeXmacs without major problems ; I mean,
without *design* problems, that can turn being impossible to solve,
in some cases : for example, if you want to port a native X application
to Windows, you must rewrite/refactor quite everything, and drop the
features that depend too much on X, if any).
Currently, neither a well defined set of widgets nor a well
defined set of advanced graphical operation is shared among
the different OSes. It translates to the problem of backing
TeXmacs on other [many :-( ?] libs, that are not very well
portable, not always complete or stable, and in any case,
it introduces the burden of maintaining the bindings to
these libraries for all the times later. Not especially
an attractive perspective :-(...
So it is a not so easy problem, and its solution is
not very clean in many cases (although in the case
of QT, it is approximately OK).