as already mentioned in the forum before, the actual version of TeXnicCenter is already more than a year old and currently there are no active developers. In my opinion one of the main handicap is the use of non-free libraries (MFC, BCGControlBar) and the commercial development environment (VC++ 6) required for development. After a short exchange of ideas with Sven concerning the migration to another library - as for instance QT or wxWidgets - he/we came to the following conclusion:- A migration to another library will imply a complete re-development of TeXnicCenter.- Furthermore it is not sure if we will find more developers then, because C++ isn't state-of-the-art anymore (especially on the Windows platform)- Maybe we should discuss a migration to a more modern programming language such as C# (.Net) or Java.

Sven told me that he would prefer a re-development in Java (maybe based on the Eclipse platform) and I'm of the same opinion. But what do others think? What are the preferences of the community? Is someone interested in supporting such a "new" project?

roman wrote:After a short exchange of ideas with Sven concerning the migration to another library - as for instance QT or wxWidgets - he/we came to the following conclusion:- A migration to another library will imply a complete re-development of TeXnicCenter.- Furthermore it is not sure if we will find more developers then, because C++ isn't state-of-the-art anymore (especially on the Windows platform)- Maybe we should discuss a migration to a more modern programming language such as C# (.Net) or Java.

Sven told me that he would prefer a re-development in Java (maybe based on the Eclipse platform) and I'm of the same opinion. But what do others think? What are the preferences of the community? Is someone interested in supporting such a "new" project?

If you're really going to rewrite stuff (from scratch) I would recommend that you're also switching the programming language. C# and Java are revolution whereas C++ is the bible

Eclipse is by far not the best "thing" in the world but it provides a lot of stuff which needn't be written "by hand". So for reengineering it is IMO the most suitable way. And, when provided as a plugin, it fits into a developer's IDE so he doesn't need 100 apps for doing his work.

As for the support part: I would be interested in helping the new TC but I can't give guarantees in what way I might help.

Moving from C++ to .NET (any flavor) or Java sounds like a good idea... I would have to agree that Java would probably be the best choice: The Eclipse IDE is free (v. VS2005 and soon-to-be VS2008, though there are "Express" versions available, with limited functionality). Maybe TeXnicCenter could even support more than the Windows platforms in this case. Eliminating commercial components might be a good idea as well.

I too would be willing to assist with the effort if it involves C#, VB .NET, or Java.

I think that the discussion of language is a side-issue. If C++ offers the best tools for the job, then use it; if C++ isn't fashionable, tough!

(BTW the *compilers* in the free versions of MS VC++/VB/C# kits appears to have no restrictions; it is the IDE capabilities that are limited. To prove this, you can do things with SharpDevelop using the MS compilers that you cannot do in teh MS IDE.)

The aims:(a) remove dependency on proprietary libraries(b) make cross-platform(c) build on the excellent functionality of TXC(d) make migration to new app as easy as possibly for usersare all good and can be done in almost any language (bar MS-specific ones and Mono helps with even that).

From a personal point of view, I like my apps to look native on the platform, not the same everywhere. That makes life harder in Java (but possible).

Qt is used very effectively in TeXMaker. But (big but) it has free and commercial licences and isn't open source.

Personal preference is Python+wxPython. Cleaner code than Java; inherently cross-platform; Python available by default on most *n*x platforms (and maybe soon on Window$); exe-builder kit for Windows until they catch up; all open source; native look (where one exists) on all platforms; licence less restrictive than GPL or Qt. (there is a binding for Qt to Python).

Please, do not use java. Until now I still have not found a stable java application for Linux and for windows.There are open source cross platform GUI (the same for Unix, windows, Mac), and there is gnu c++ which can easily compile visual c++ programs (except for MFC and visual library call). There is a port of gcc for windows. Your program will be immediately suitable for Linux or Mac!

This seems to become the common "what's the best programming language" discussion, so I would like to give my opinion here again, to push this thread into the right direction

At first two comments:

Some people have stated that the current Microsoft C++ compilers are available for free. That is right, but what is not included in these free distributions is the MFC, the class library the whole TeXnicCenter is based on. The MFC is still only contained in the commercial versions of Visual Studio.

When taking the effort to switch to another language and rebuilding TeXnicCenter up from the scratch, than I'm sure that it should definitely be a language, that provides full cross platform support. That's why I think that C# is no good choice, though I really think that it is a great language (and though there is a Linux port called Mono).

The idea of changing to java was not because I think that java is the world's best language. The by far best thing I can see here is the availability of the Eclipse platform (to be more exact: the Rich Client Platform RCP). I do not know of any comparable framework for building integrated development environments (and TeXnicCenter is one) for any other programming language -- and that for free and as open source

For those who do not know about the Eclipse framework (RCP): Eclipse is far more than just a Java IDE. Instead RCP is a java framework for building java applications. Because the eclipse IDE is based on this framework by itself (like a lot of other development tools) the advantage for re-developing TeXnicCenter using this platform would be, that there are many parts needed by TeXnicCenter are already available, like dockable windows, editors with syntax highlighting, handling of projects, integration of compilers (LaTeX is also a compiler) including the parsing of their output and building error lists, document navigator views, a solid plug-in-mechanism (interesting for integrating third party tools, wizards, etc.) and a lot more.

This would bring us the advantage, that we always get when using established frameworks: A lot of features for free without writing a single line of code and because of Eclipse's popularity this code is well tested and rock solid. Further on the Eclipse framework is so widespread, that there are already several books available on how to work with this.

Another big advantage of the eclipse platform regarding the GUI side: It does not use Java Swing which still does not look as good as native applications on the different platforms. Instead the RCP provides its own component library and this one uses the native operating system controls. So RCP based applications are looking really good on Windows, Linux, MacOS and so on. Just download Eclipse and give it a try

And to give the last bit: There is already a LaTeX editor based on Eclipse which is also open source -- I have lost the name of the project, but you can google for it. So a lot of the base functionality like LaTeX syntax highlighting, parsing LaTeX output and so on is already available There are two possible ways, how we could use this already existing base:

We could contact the developers of this eclipse based LaTeX project, ask them if they would allow as to put our power into the project. Than we could rename this thing to TeXnicCenter 2 or something similar to give it the popular TeXnicCenter brand

If they would keep there project as it is, we could take their sources into our own repository and start our work independently.

If we could find some people that really have the time to continously work on this project and who have the relevant programming skills, I would care about the organization and so on. But we really need people who have the time to work on this -- otherwise it would be wasted time...

I haven't tried them much, but TeXClipse seams to be quite powerful with quite few things already implemented. However, it seams that the development of both projects has stopped.

I believe, that if Eclipse is to be used, TeXClipse could be a good basis. Providing that all the functionality that TexniCCenter already has, is implemented as well (like customizable shortcuts for environments, auto completion etc.).

Has anyone been thinking about wxWidgets library (http://www.wxwidgets.org/). That one already has Scintilla component integrated as far as I know. A very good IDE code::blocks (http://www.codeblocks.org/) is already developed with that library, and maybe some things could be used from there as well. It has bindings for C++, Python. But than at the end, I'm not much of a developer, so I can not discuss about technical capabilities of programming languages etc.

May I suggest you to give a look to the Code::Blocks IDE for C++ (http://www.codeblocks.org)?It is written in C++ with wxWidgets; it is a very modular IDE (functionalities are provided by plugins); its editing component is based on Scintilla (and thus it can already highlight LaTeX files). And of course it is open source. If you wish to give it a try, I strongly recommend to install the latest available nightly build.

One further possibility is to test in wxPython and freeze in wxWidgets if you decide that you really need the speed (you probably won't).

If the GUI and model are kept properly separate, then the issue of PyQt versus wxPython can be deferred. there's a lot of non-visual stuff to do:

Define OutputProfile class with load/save from/to XMLDefine Project class with load/save from/to XMLDevelop stdio+stderr and logfile parsers for error/warning detection and locationDevelop source file parser for structural analysis (as used by TXC's browser panes)Develop code completion facilities (if liked) which will actually deal with definitions in packages and files. (This is hard, it implies close to a LaTeX parser.)

Most (all?) of this can be done with pure Python (or C++, or...) classes and tested without a GUI.

Just to encourage budding Pythoneers: running LaTeX on a file and capturing the terminal output as a list of strings is less than 30 lines *with* comprehensive error detection and platform-dependencies sorted. In fact, it would be less but the base class used also checks for the subprocess being a GUI program or not and alters things accordingly.

I think that there is a danger of getting hung up on the GUI. That's only part of making (La)TeX user-friendly for GUI-liking users. Things like profiles and projects (essentially a specialised form of 'make' system) are also important.

Get the model reasonably right and the GUI is there to exploit the mode's facilities.

If you have a large base of C or C++ code, it makes sense to continue to use the same language instead of re-implementing everything in Java.

Moreover (and it is a more general advice), I warn you against coding in Java like you formerly coded in C++. It's the quickest way to make a slow and bloated application.For example, I just coded an application for my company in a C-like, low-level language, and one of my colleagues has done the same in Java. My programs does the job 30 to 50 times quicker than his'. I don't know where his bottlenecks are, but my general impression is that he did not learn/practice enough about the Java subtleties to make a quick and low-memory application with it. To tell the truth, I do not know more than he does, but I know at least that you better think and practice twice before coding something big in Java.

There is a C/C++ development toolkit for Eclipse, which you can download here : http://www.eclipse.org/downloads/ (it is the 3rd download link : "Eclipse IDE for C/C++ Developers"). So you can get the advantages of a modern and free IDE, with quite a lot of momentum. And I think you can take advantage of the Eclipse framework with C++ too.