texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] Re: Guile Cygwin


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Re: Guile Cygwin
Date: Wed, 23 Oct 2002 15:47:24 +0200 (MET DST)

> No matter what I look at, it still looks like using the base Win32
> layer in Windows is the best.  There is no licensing or 3rd party code
> to worry about, and we then have full control over everything.
> Qt has a licensing problem, this would mean a windows port would not be
> free.

> WXWindows has support problems and Joris has advised me against it.

You put this a bit crudely. I just noticed that the menus have been
implemented in a very restrictive way, which leaves little room for
our fonts and symbol menus. Several other people told me that
the Wxwindows developers are not very responsive and not very open
for contributions from extern people.

>  Gtk, as I have been advised by one of my peers, may not be very
> suitable for the operation.  It is still up in the air at this point.

Gtk lacks of native look and feel.

> The Win32 port, as we see it, may just consist of a rewrite of texmacs
> XWindows calls to the windows environment.  This may be difficult as
> there is not direct mapping between the toolkits.

What toolkits would you use for Windows in this case?

> I realize that a Win32 port will not coexist with the POSIX
> distribution well, and may require 2 seperate development branches.
> This may be unavoidable though, as the GUI is not the only problem with
> the port.  There are some other areas of the code which just aren't
> portable.  The only way to get around this would be to Do you have any
> suggestions??

I strongly emphasize that the TMGUI protocol will allow us to
separate all GUI stuff from the main program. When ready,
it will enable us to implement as many GUI's as you want for
as many distinct architectures as you wish. So there is no problem
for having 2 or even more development branches for the GUI (but only
for the GUI).





reply via email to

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