Quote: Original post by Anonymous Poster
Instead of forking anjuta or an existing IDE to add and change things that are amiss...

Forking a codebase requires comprehending the codebase. As many codebases are poorly written, poorly organized and poorly documented, that is a much larger task than many image. Forking is only practical for users familiar with the codebase already, as in the GCC/EGCS debacle.

Quote: Original post by smiley_horse
There is - quake, wolf, unreal - are those kick a$$ enough for your taste?

Technically, those are all the same game - an FPS where you shoot stuff. *yawn* For those of us who almost never play FPSes, *double yawn*


I think we've belabored the ideological and commercial differences between closed and open source enough, so I guess we can close that chapter and move on?

Quote: Original post by Oluseyi
Forking a codebase requires comprehending the codebase. As many codebases are poorly written, poorly organized and poorly documented, that is a much larger task than many image. Forking is only practical for users familiar with the codebase already, as in the GCC/EGCS debacle.

Yes, it's daunting to read code. Especially since programmers think everything they didn't design themselves is a mess. If you're methodical about it, you will manage to grasp it and understand the design. Whether you'll save time or not shipping the product, I can't say for sure, as I have only anecdotal evidence. I do know, however, that in the maintenance phase (which is the largest part of a software's lifecycle, usually) there will be benefits, as the original codebase can be assumed to be reasonably well tested and debugged. In this case, it seems to be a "release once upgrade never" product (which kind of turns me off), so maybe it doesn't matter.

Quote: Original post by Oluseyi

Quote: Original post by smiley_horse
There is - quake, wolf, unreal - are those kick a$$ enough for your taste?

Technically, those are all the same game - an FPS where you shoot stuff. *yawn* For those of us who almost never play FPSes, *double yawn*

The master of unsolicited condescension strikes again. How about Neverwinter Nights, then, or Heroes of Might and Magic III, Descent 3, or Railroad Tycoon II? (There are also things like Medal of Honour and Doom 3, but apparently those are exactly the same as Quake.)

Of course, it's no secret that the Linux gaming market is minimal, but there are a few good games out there.

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.

Quote: I think part of the reason the GPL zealots are after you is because you propose to give something to them for free, and yet in their minds, free includes source code.

Nobody is after him. Nobody complains because he doesn't give away his code. It's his own words - I haven't seen a post on this 9 pages where someone demand him to release his code. Nobody even claims he should release his ide for free. It's only his artificial construct that ppl refuses his code because there is no source. Someone may refused to do a non-payed work to his closed project, which is more then understandable. And stupidndess saga continues with this thread & claim that those are "zealots" cause they don't wanna work for free for him. If you ever released your app, even in alpha & without single source file and asked ppl for help - I bet there would certainly be a lot who whould like to help. If you ever had something to release & give for free, you would, and you wouldn't start this thread. But as I said before he may have his own beliefs he wanna claim and that is rather why he started this thread. I wish you goodluck - but you would probably do much better to invest your time to learn how to use make properly then to claim it's crapy tool.

By the way those "zealots" you are talking about gave u the very same linux you are using (for free I guess), they gave you gtk and source - so you can fix what you think is wrong & all other tools you are using and you still call them idiots. You are talking about hacking in gtk itself above - isn't it nice to have that source indeed? Anyway why are you bothering then if it is so bad - invest your money and time in windows & visual studio instead. But I guess you are saving your money buy using free (as in beer in your case) tools ... I would do if I had a bussiness.

ps.
Don't take me wrong - I'm not saying this caz I want to use your ide - I'm quite happy emacs users since almost 10 years back - not even visual studio has made me change.

[Edited by - smiley_horse on February 20, 2005 10:44:12 PM]

Quote: Original post by Miserable
The master of unsolicited condescension strikes again.

Ah, purveyor of foul inaccuracy! I smite thee with reason! [smile]

I never said there weren't great games for Linux. I was merely pithily pointing out that that wasn't a great representative sample. I really shouldn't talk, though, as I don't play many games anyway. Call me when you get NBA Live, though [smile]

Quote: Original post by Anonymous Poster
Yes, it's daunting to read code. Especially since programmers think everything they didn't design themselves is a mess.

Especially when the code structure isn't documented.

Quote: If you're methodical about it, you will manage to grasp it and understand the design. Whether you'll save time or not shipping the product, I can't say for sure, as I have only anecdotal evidence.

But therein lies the problem. If it is an unmeasurable cost/benefit, then how do you weigh it against writing from scratch (which you can estimate within reason) as a delivery constraint/factor?

Quote: I do know, however, that in the maintenance phase (which is the largest part of a software's lifecycle, usually) there will be benefits, as the original codebase can be assumed to be reasonably well tested and debugged. In this case, it seems to be a "release once upgrade never" product (which kind of turns me off), so maybe it doesn't matter.

I don't know that we can make either assumption, "in this case." Yann L has had tremendous problems with Gtk, which, in it's 2.x incarnation, should be stable, reasonably well tested and debugged, no? Further, ISTR him saying that the project could gradually move toward a fully open source release as the proprietary dependencies are eliminated.

In the final analysis, what we see is that software development remains a challenging process, and open source is not a panacea, or, in the words of Jamie Zawinski, "magic pixie dust" (I love that quote).

Quote: Original post by Oluseyi
In the final analysis, what we see is that software development remains a challenging process, and open source is not a panacea, or, in the words of Jamie Zawinski, "magic pixie dust" (I love that quote).

Heh, what perfect closing words for this thread !

Although I don't feel too good about doing so, I'm going to close this thread, so to avoid further flames. But besides these flames, it was an interesting discussion, so I would like to thank both sides for presenting their points of view. This thread definitely helped me to harden my current stance. We will release the IDE, free but without source, and I won't care about the "GPL zealots" anymore. I realized, that they simply are not our target market, so to speak. Years ago, they made up the large majority of Linux users, but times are changing. This thread has shown, that many people using Linux are in favour of closed software under Linux, and even commercial one. That's a good and promising development, IMO.

Any more questions & comments are welcome by PM.