Quote:Original post by Yann L
Quote:Original post by Prefect
What "entire concept" are you talking about? The "entire concept" of Anjuta (and KDevelop, and ...) is to create a good IDE. If you "don't like" that, I wonder what you're here for.
I guess our definition of the terms "good IDE" differ significantly. Anjuta is no good IDE, and neither is KDevelop. Here, I'll give you a quick rundown over what I dislike about Anjuta (from the top of my head, there are probably many more subtle points):
Please note that I do *not* think Anjuta or KDevelop are good IDEs. However, that's not because their respective developers don't want to create a good IDE or because they don't know what a good IDE needs. It's because creating a good IDE is hard.
Quote:
* Its complete reliance on an obsolete and crappy build system
* The lack of any working source tree management (forced autotools source structure, no virtual tree, etc)
* No multiple dependent projects and targets within a solution
Those are all really only one thing: Relying on autotools per default. I mostly agree with your sentiments here, but (a) linux IDEs have to survive in a preexisting environment of open source development where autotools are widespread and many people still believe Vi and Emacs are somehow the ideal "development environment", (b) the choice of autotools is independent of the rest of the project, at least for KDevelop, (c) the developers are aware of this problem and work is actually being done on that.
If you don't address point (a), then "third party developers" (like the ones you'll find here on Gamedev) will still use your IDE, and that's fine. However, it won't find acceptance with the developers who work on major opensource projects.
Quote:
* The fact that the interface customizability is exactly zero
* The GUI is clumsy and confusing, and doesn't support an efficient workflow
These are hardly reasons for a full rewrite. Most of these things can be changed with relatively little work in a GUI Designer (like the one that is quite well integrated into KDevelop ;)), or to accelerators, etc. Yes, doing tweaks like that is a lot less fun than rewriting something from scratch.
Quote:
* The debugger integration is very bad (this also applies to other external tools, such as gprof, valgrind, etc).
Full ACK on that one.
Quote:
Basically, it's messed up beyond hope (well, according to my definitions ;) Fixing it by a fork would be more work than starting a new IDE from scratch.
Yes, existing IDEs have many problems. But they had many more problems in the past that have been fixed since then. Do you really believe you won't run into the same problems?
Quote:
Quote:Original post by Prefect
In fact, I would argue that the build system is actually one of the *least* important aspects of an IDE.
Tell that the project managers at any large software company ;) The build system is actually an extremely important part of an IDE.
If a software company is spending so much development time on the build system, I'd seriously doubt its ability to survive for too long. Once the build system is in place, you should no longer have to worry about it. Remember that in normal Linux IDEs, the build system is *integrated* into the IDE, but it is not a *part* of the IDE. So the only build system-related code in the IDE is the code that configures the buildsystem. Compare my rant about integration in the next section.
Quote:
This is actually the magical two words: seamless integration. That's what pretty much all Linux IDEs lack (except Eclipse). They're more a patchwork of tools that were thrown together, and lightly coupled by the IDE. Many current Linux IDEs are nothing but a graphical frontend for autotools, gdb and make. And this is not what an IDE is supposed to be - it is supposed to tightly glue these tools together, so that as a user, you don't even feel like using separate tools anymore.
I mostly agree here (more integration would be better), though I believe the main reason Eclipse seems better integrated is that it only integrates *with itself*, and doesn't actually integrate much with the entire world of open source *around it*. This isn't so surprising: Java (where Eclipse comes from) doesn't have as many open source projects based on it as C and C++, so there's less of an outside world for it to integrate in.
Seriously: Visual Studio seems so integrated mostly because there are no outside tools it has to integrate with (yes, I'm oversimplifying, but bear with me for a moment). The entire build chain comes with Visual Studio, not with Windows. This is very much unlike the situation in Linux, where the build chain comes with the distribution, not the IDE. Integrating with the outside world (and all the strange and subtle differences between distributions, build tool versions, etc.) is hard.
I'd like to stress this point, as it really is important. In a way, Microsoft has it a lot easier than the developers of Linux IDEs. Visual Studio can just say "Okay, all developers on a project are going to use Visual Studio". Linux IDEs can't do that, unless they want to limit their user base to very small, tightly knit teams (and corporations where the choice is IDE is forced by management). Just like there are endless, essentially pointless debates about "Vi vs. Emacs" or "Tabs vs. Spaces" or "camelCase vs. loads_of_underscores", you will never get all developers in a real life opensource project to agree on a single IDE.
Of course, you're free to ignore all this and create an IDE that only integrates well with itself, but not with the development world around it. That's fine, but at least you should be aware of why open source developers will complain.
cu,
Prefect
P.S.: Unfortunately, I'm more of a Qt/KDE person, so I can't help you with the Gtk problems.
