Lionel Debroux (./1) :
Drawbacks of the Delphi IDE:____* Windows-only (though it runs on Wine - note that I have never tried communicating with an emulator or a real calc under Wine).
Last I checked, TIGCC IDE was extremely buggy in WINE and couldn't even compile a project. It's not an option to be considered seriously. Not to mention that switching from a native GNU/Linux executable (KTIGCC) to WINE would be a major step backwards.
____* written in a lesser-known language
Lesser-known and proprietary. And there isn't even a free-of-charge version, except an ancient version (Delphi 6 Personal Edition) which generates executables incompatible with Vista and which isn't available anymore. And it can't be cross-compiled.
____* two incompatible code bases, both of which need to be maintained for a while because they have different sets of users:
________* KTIGCC 1: uses Qt/KDE 3.x, *nix only. Usable on GNU/Linux distros which focus on stability (e.g. Debian Etch, the upcoming Debian Lenny, and derivatives thereof). Given the rate of Debian releases (20-23 months for the three last releases), this should be maintained for more than two years;________* KTIGCC 2: uses Qt/KDE 4.x, *nix only. Usable on GNU/Linux distros which focus on making their users test out the latest technologies (e.g. Fedora). Kevin wrote that KTIGCC 2 is not feature-complete, IIRC. KTIGCC 2 with fixes for non-portable constructs will become KTIGCC 3.
Only one is needed and will be supported at a time (i.e. KTIGCC 1 will stop being supported as soon as KTIGCC 2 is ready). It is perfectly possible to install KDE 3 libs under KDE 4 or vice-versa. (In fact I'm shipping KTIGCC 1 in current Fedora just fine.) There are even KDE 4 libraries in Lenny (kdelibs5), though an updated version may (or may not, I'll see if there'll be any reason to require 4.2) be needed for the final KTIGCC 2.
____* on Windows, and a number of GTK+/Gnome-based *nix, users have to install Qt and the KDE framework.
A non-issue.
On Windows (majority of the user base, as far as we can tell), kde4win is currently far from production quality...
That will improve over time, it should already be much better when KTIGCC 3 will be ready.
linking to emulators & real calculators is not externalized
And that's by design.
____* it's a leap backwards in the footprint of the TIGCC environment (we're talking dozens of megabytes of framework to run a small IDE which has few features that other IDEs don't have, and misses a number of features that common IDEs have...)
I don't see the problem, really. Users these days stream or download many more megabytes of videos or music than KDE takes. It's downloaded in only a few seconds with a modern broadband connection.
and the complexity of the installation process.
The kdewin-installer is fairly straightforward.
____* it doesn't go far enough for modularity and flexibility.
That's an assertion I don't agree with at all.
In another (French-speaking) section of yAronet and on the GCC4TI feature request tracker (between others), we have discussed several ways to go forward from that situation:
All your solutions are not being considered for TIGCC at all (the first one is a non-solution, the other 2 are huge steps backward), so they'll lead to your "fork" becoming a radically different project with a completely different codebase.
* move enough things outside from the Delphi IDE so that it becomes little more than a graphical front-end to tools that do the actual work (and thus, it becomes rather low maintenance).
This is a non-solution because it doesn't solve the real problem: we still have a second codebase and it's still written in a proprietary lanugage I can't even compile. It also requires major rearchitecture of both the Delphi IDE and KTIGCC (if you want to actually share the code), and all the GUI code, which is obviously most of the code in an IDE, still needs to be duplicated (you can't put GUI code in a library shared between Delphi code and KDE code as they're using completely different GUI toolkits).
So TIGCC will never consider this solution, if you go down this road in GCC4TI, you're on your own.
This is a pattern commonly used on *nix, because it is well suited to both scripted use and interactive use, and yields low code duplication rates: let's mention only cdrtools, Sleuthkit, Nmap, MPlayer, Git and their graphical front-ends K3B/Brasero/etc., Autopsy, Zenmap, KMplayer, git-gui&gitk.
Some of your examples are really bad examples, for example the git GUIs all suck (you can't even clone/checkout a repository with them) and KMplayer doesn't look like an integrated application to the point Kaffeine (which uses xine-lib, an actual library) does.
And what you'll also notice is that all their dialogs of those frontends are inside the frontend. And as that's most of the code in the IDEs (hey, they already are frontends to GCC etc.), I don't really see much stuff left to externalize, so externalizing stuff isn't going to solve the code duplication problem at all.
____* ld-tigcc, ar-tigcc, patcher (TIGCC and GCC4TI agree that all three should be external executables on all platforms, even if that means slower operation on Windows 9x/ME);
Actually I only think patcher should be a standalone executable everywhere because I want KTIGCC everywhere, I don't think changing the Delphi code to an external patcher is that big a win (but it can't hurt if done properly, with no regressions). The broken link.dll interface is a bigger problem. Also note that the patcher is an extremely small piece of code (and should ideally go away entirely, GCC should just be fixed to output the right thing right away).
____* tprbuilder, to which a compatibility mode for the IDEs' behaviour should be added (so as to preserve backwards compatibility with both the IDEs' and tprbuilder's behaviour);
As I already wrote elsewhere, it is impossible or at least highly impractical (i.e. would need a second temporary directory, and there might also be other gotchas) to build the projects using tprbuilder because only the IDE knows the current version of the source files, which are not necessarily saved (!), so it has to be the IDE writing out the sources to the temporary directory. The current version of the project options, which are also not necessarily saved (!), is also only known to the IDE. tprbuilder also can't check which files have changed and which haven't, it just always rebuilds everything. The IDEs both have clever makefile-like logic for that. So it would be extremely hard to get this right and lead to something suboptimal (with 2 or more temporary copies of each source file), whereas the current compilation logic is already implemented and just works. So what would we have to gain from this?
____* <to-be-named> application for emulator & real calculator linking. TILP's GUI-less mode can be a first step.
I consider using the tilibs directly to be a better solution here (and the one I intentionally chose for KTIGCC). As I already wrote elsewhere, KTIGCC relies heavily on the libticonv anyway (and TIGCC IDE really should too if you want to keep it long term, currently it chokes on Greek letters almost everywhere), and it also uses the cable type enums from the libticables2 to store its configuration options internally. And it allows providing the libticalcs2 progress report callbacks to display a nice progress bar for the transfers. And the library interface is well-designed and just works, using an external executable instead would save almost no code (it might even require more code, especially if you want some solution for progress reporting).
* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C++ with a dependency on Qt only. We lose some convenience classes, but we don't depend on something which won't work well for quite some time.
IMHO this is a huge step backwards, you lose all the KDE classes and end up reinventing the wheel, you'll have a hard time to find an editor component comparable to the KatePart, you also get less nice file dialogs under X11 and you win... essentially nothing. And I also disagree about the "something which won't work well for quite some time". Something which still has some glitches left now, OK, but they'll get fixed.
So TIGCC will never consider this solution, if you go down this road in GCC4TI, you're on your own.
* scrap both the Delphi IDE and KTIGCC, and rewrite the IDE in C#/.Net. Portability would be good (through the use of Mono), but from a user's POV, that's trading a non-default-installed framework with another non-default-installed framework (only a different group of people would be inconvenienced).
This is an inferior framework, you'll also have a hard time supporting Mono, especially if you rely on the WinForms (the alternative being GTK#, most Mono apps use that) and there are some patent concerns with Mono (for example it's still not included in RHEL, though RH grudgingly agreed to include it in Fedora).So TIGCC will never consider this solution, if you go down this road in GCC4TI, you're on your own.
TIGCC's proprietary build system (TPR)
I'd rather call it "specialized". I don't see how it is proprietary, it's a nice clear INI format.