mailing-list for TeXmacs Users

[Joris van der Hoeven <address@hidden>]

> my humble try to revive a flamy topic :)

My humble try to close it again.

> I know that there's some work in progress for porting TeXmacs to another 
> toolkit, but what I want to say in this message is that it should really be 
> a 
> priority, for two reasons especially:
> 
> - the trivial reason is that it would make TeXmacs integrate into a user's 
> desktop environment (which is not that trivial, in the end; think of drag 
> and 
> drop issues, for example);
> - the very important reason is that there are *many* {Qt|gtk+2|Wxgtk..} 
> programmers, while there is really *few* who can program using texmacs' own 
> toolkit.

I agree, but this takes quite a lot of time. I am willing to encapsulate
the current interface in a clean and abstract 'TMGUI API'. Then you may
implement as many specific GUI's (Qt, Gtk, whatever) as you want.
However, I will not have time to do this second part of the job.
If you volunteer: great.

Also, Dan Martens is writing a Windows port for the current interface.
Porting TeXmacs to Windows is a higher priority as porting TeXmacs to
other toolkits. As soon as we will have a good Windows port,
then the task of ports to other GUI's will therefore become
less urgent for us. Indeed, one of the major reasons for
using other GUI's was portability.

> Speaking about usability, TeXmacs (absolutely?) needs:
> - popup windows for confirmations and so on
> - popup dialogs for configuring user options and preferences, page layout, 
> and 
> so on
> - dialogs to do customization things, such as visually edit a style, header 
> and footer, choose what kind of numeration to use via an explicative UI ...
> - mouse-less editing (this is __very__ important)
> - ... I could go on for a while

I agree (although some of this behaviour might have to be selected
in the user preferences). Notice however that some of these things
might easily be implemented in the current GUI too.

> So I ask wether wouldn't it be possible to feature-freeze texmacs for a 
> while 
> and concentrate on the port to another (modern, widely-used, 
> easily-accessible) toolkit?

Certainly not. I don't have time to spend a few months on such
issues at the first place, so other will have to do the job.
Secondly, I don't like the work, so I prefer others to do the job.
And finally, many users expect other improvements in TeXmacs
than user interface stuff.

> How don't know how many *active* programmers are there at the moment, but I 
> guess the task couldn't take much longer than a couple of months, even 
> having 
> a small team working on it.
>
> This would allow many users to contribute their own code, what they now 
> won't 
> do as they don't want to invest time learning how to use a toolkit they're 
> not going to use somewhere else.

It is not clear though that such an investment would attract so many
new developers. GUI interface design is *not* the part of TeXmacs
where help is need most urgently. We rather need good documentation,
more and better connections to extern software, better style files, etc.
Each of these issues is independent from the GUI.

> Moreover, there are tools such as glade (gtk) or qt-designer (Qt) that 
> would 
> let you and any other programmer tweak the interface quite easily.

This is precisely a thing I want to avoid, because these tools
have less structure than the approach used in TeXmacs.

Notice also that in the long run, the whole GUI issue will disappear:
it will become possible to see the GUI as a TeXmacs document.