Collaboration in open source

[magland]

I move this discussion to this thread to respect QDevelop.

Where do you see the collaboration here? Don't get me wrong, you're absolutely free to do that and it could reveal extremely cool though it will probably require a bunch of work from you to create an abstraction layer over 3 very different frameworks (in terms of API and impl I mean). The fact is that you just take things ONCE they are ready, which is normal to make your IDE stable, but you DO NOT cooperate allow these modules to get ready sooner... That would be collaboration.

Yes, you are right... what you describe is collaboration in the proper sense of the word. I meant that open-source provides a different type of cooperation, I should not have used the word "collaboration".

Your approach of project handling is not such a fundamental difference... The fundamentals of an IDE are :

• loading project files
• editing sources
• compiling

All the rest is good to have but not "fundamental", at least that's my understanding...

I still say that Handcoder's IDE is fundamentally different approach... maybe it will become more clear in the next release of September 5th.

[wysota]

I wanted to bump this thread up, because I think it is a very interested subject nobody had time or interest to discuss. Recently we had at least two threads asking why do Qt IDE authors not cooperate with each other and instead lead separate projects. Maybe there is some space for discussion of the issue and maybe this thread could be used for that.

So... feel free to discuss

Oh, I'll just add that both fullmetalcoder and Magland are Qt IDE (different, of course) authors and QDevelop is another Qt IDE project.

[Kumosan]

I don't think it is true that open source developers don't cooperate with each other. They just don't give up their own projects so that noobs are spared the tremendous effort to evaluate more than one alternative. I usually get a bit aggressive when I attend to topics like that. "Why are there so many different xxxx?". Simple, because ppl. start projects to learn something. To have fun. Because existing projects don't provide exactly what they have in mind.

I have several small open source projects on sourceforge. I started them to experiment with certain features of Qt or because I needed one single feature, which no other similar project had. My main objective was not to give or develop free software to the community. I did it solely for me, but I decided to make the results of my work public.

I do cooperate with other developers. There is a certain information exchange between me and the developers of other comic readers or other bittorrent clients. Not once one of the other developers asked me to give up my code and joind their development team.

To think about it, this is really strange. In a certain way open source developers not only cooperate with each other, but also at the same time compete with each other. However, those "Why are there so many xxxx" questions never come from my "competition" to get me out of their way, but usually from lazy bugs, which never wrote one single line of code themselves.

[fullmetalcoder]

I don't think it is true that open source developers don't cooperate with each other. They just don't give up their own projects so that noobs are spared the tremendous effort to evaluate more than one alternative. I usually get a bit aggressive when I attend to topics like that. "Why are there so many different xxxx?". Simple, because ppl. start projects to learn something. To have fun. Because existing projects don't provide exactly what they have in mind.

I do agree. I myself also started working on Edyuk (which was named DevQt back then) as for my own use without any ambition. At that time if someone had told me that it would end up featuring debugging and completion I'd probably have laughed at him because it sounded so much to do... I did have a lot of fun experimenting (I mean both doing experiments and getting some experience out of them ) and it turns out that these feature came, among other things not only because people asked for them but also because they brought new challenges (man I like challenges so much... ). Now, if someone feels that my work is useful to him, either as an example, a source code mine or an everyday tool I'm all the happier and it gives me more motivation to keep working on Edyuk but it is not the only motivation I have and programming remains just a hobby...

To think about it, this is really strange. In a certain way open source developers not only cooperate with each other, but also at the same time compete with each other. However, those "Why are there so many xxxx" questions never come from my "competition" to get me out of their way, but usually from lazy bugs, which never wrote one single line of code themselves.

I'd say collaboration and competion are not incompatible... I've been in contact with pasnox (author of Monkey Studio) for monthes and we had many interesting talks about various aspects of our softs which allowed improvements on both sides, which I call collaboration, without forcing us to merge so competition is still there and I'm convinced it's a good thing as it gives a wider choice to the end user and tend to boost the development of all projects

[wysota]

I'd say collaboration and competion are not incompatible...

Qt is the codebase of KDE. Disagreements between KDE and GNOME are well known in the freedesktop world. Based on that one would say that Trolltech (hence Qt) should take the side of KDE in the discussion, because it's a natural way to encourage the use of their product.

This might sound surprising, but did you know that Trolltech actually supports GNOME? And I don't mean "support" like in having the Cleanlooks style and integrating with the desktop. I mean support as in encouragement and financial help. I think this is a perfect example of compatibility between collaboration and competition.

[magland]

Thanks, wysota, for bumping this thread up, and I only notice it now.

It seems there is a kind of concensus in these posts that it is good and prosperous to have multiple open source projects existing simultaneously (for example IDEs), and implicit cooperation (and competition) can both exist.

What I am amazed at is how open Trolltech is with their source, which I am very pleased with... and it reflects the fact that Qt library is a great product! The best I have ever seen. And this encourages me to open all my sources. It's a good policy. Why? Because it allows the programmer to focus solely on good coding, without worrying about protecting this or that piece for proprietary reasons. But there also needs to be structure. Ideally a single person, or a close working group, making the decisions about the general framework of the application.

----------------------------------------------------

As a side note, here are three (of many) examples of how I have benefitted from Qt's open source philosophy.

From the very start of HaiQ I just grabbed the Qt source for "qmake" and rewrote a little of the main.cpp, took out the unnecessary stuff... and voila I had a 100% perfect project parser which I have not looked back or modified since the original version [except to adapt a couple things for small maintainance]. Now if you compare the Qt IDEs (and please take the development version of HaiQ - see http://groups.google.com/group/haiq), I think it's plain to see that nobody has a better project parser than haiq. (Perhaps, someday, they'll all use my strategy.)

A second point. For code completion and class browser, HaiQ simply looks in header files to see which files are included, parse those with ctags, and that's it. All the source is there, so no problem. I don't treat Qt classes and source code any different from other libraries. This is only possible because all the source is there (thanks Trolltech!)

Third. There was a recent thread with an issue about designer integration code. In the end, I found the best solution was to just grab Qt's own designer code. If you try the IDE's I think you will find that HaiQ has the most complete and reliable designer integration. And it's not much of my work - just the right code in the right place.

These examples show that open source really can benefit the programmer, if it's used right. And I think that's the way things are moving in general --- open information and free software.

[wysota]

Third. There was a recent thread with an issue about designer integration code. In the end, I found the best solution was to just grab Qt's own designer code. If you try the IDE's I think you will find that HaiQ has the most complete and reliable designer integration. And it's not much of my work - just the right code in the right place.

Oh, I can't agree here - this is the worst you could have done. If Designer changes, your code will still use the old one so you have to reinstall your application with every new release of Qt which is not good. The Designer comes with its own shared library and you should be using it instead of merging with its source code.

[magland]

Oh, I can't agree here - this is the worst you could have done. If Designer changes, your code will still use the old one so you have to reinstall your application with every new release of Qt which is not good. The Designer comes with its own shared library and you should be using it instead of merging with its source code.

Okay, maybe you are right. But for now it works great. In future, I'll adapt.

Edit:
Actually, I point out that I am using the shared library that comes with designer. I just take the code from Trolltech that represents the front-end of designer. So there is no need to re-install with each new release of Qt.

[wysota]

I don't know what you mean by the frontend here, so I can't argue with that. But if you take some code from Designer instead of calling the original code from a shared lib, when the original code changes, yours becomes outdated. That's not a big problem with qmake as it rarely changes and besides, the Trolls are working on another solution that would allow using a shared library as well.

[magland]

I don't know what you mean by the frontend here, so I can't argue with that. But if you take some code from Designer instead of calling the original code from a shared lib, when the original code changes, yours becomes outdated.

But it's no problem. If the Trolls change the shared components of designer (i.e. QtDesignerComponents), then haiq is automatically updated. If they change other parts of Designer (such as the main window actions which are not contained in a shared library), then no IDE could possibly keep up to date automatically. But HaiQ would still work fine. Also, HaiQ would have the easiest time of getting up to date, because I would simply copy the new files from the Qt source into the designer plugin (make the few minor changes), and we're done - twice a year.

[fullmetalcoder]

From the very start of HaiQ I just grabbed the Qt source for "qmake" and rewrote a little of the main.cpp, took out the unnecessary stuff... and voila I had a 100% perfect project parser which I have not looked back or modified since the original version [except to adapt a couple things for small maintainance]. Now if you compare the Qt IDEs (and please take the development version of HaiQ - see http://groups.google.com/group/haiq), I think it's plain to see that nobody has a better project parser than haiq. (Perhaps, someday, they'll all use my strategy.)

I'll never end up using your "strategy". Not because I'm jealous or warry about some maintanance and embedding issue but because I have a very different philosophy concerning project files... Actually I considered using your "strategy" monthes ago but I dropped this idea for a simple reason : qmake is NOT suitable as a project parser/editor because it is not designed as one... What an IDE needs is to construct a smart data structure from a project file and more importantly one that is easy to modify in any sort of way needed by project editing. On the other hand qmake does not create such a structure but instead it "interprets" the content of the project file (as if qmake projects where kind of meta scripts used to build makefiles).

As for designer integration your approach does not bring that much more features AFAIK...

[magland]

I'll never end up using your "strategy". Not because I'm jealous or warry about some maintanance and embedding issue but because I have a very different philosophy concerning project files... Actually I considered using your "strategy" monthes ago but I dropped this idea for a simple reason : qmake is NOT suitable as a project parser/editor because it is not designed as one... What an IDE needs is to construct a smart data structure from a project file and more importantly one that is easy to modify in any sort of way needed by project editing. On the other hand qmake does not create such a structure but instead it "interprets" the content of the project file (as if qmake projects where kind of meta scripts used to build makefiles).

Good point. Probably this strategy is not suited to most IDE's which allow user to graphically edit the project - add files, switch configuration, etc. HaiQ is fundamentally different in that it treats the .pro file as source code. But I do think some day HaiQ will have the capability of editing .pro files in a graphical manner - like click to add files and such. To me, that's analogous to functions for automatically adding methods to classes and such. They will come when they are ready (unlike visual studio who put those types of code generation in before she knew what was smart). But you know, I enjoy having everything in front of my eyes. It goes with my philosophy of an IDE. But it doesn't fit everyone.

As for designer integration your approach does not bring that much more features AFAIK...

You know, sometimes it's the little things that make a big difference. It's comforting for me to know that it's not my code, but Trolltech's at work when I am editing my forms. Sometimes I wish the trolls could write my whole IDE

[wysota]

On the other hand qmake does not create such a structure but instead it "interprets" the content of the project file (as if qmake projects where kind of meta scripts used to build makefiles).

I guess Edyuk won't manage to parse my project file then... What a pitty... Jeremy's IDE did (and I was very positively surprised)...

[fullmetalcoder]

I guess Edyuk won't manage to parse my project file then... What a pitty... Jeremy's IDE did (and I was very positively surprised)...

Have you tried? It actually performs quite well with all construct except :

• wildcards
• for loops

but this is obvious since resolving these would can not be done in a "time-independent" way and would need complicated interlaced file/folder/variables watch... All the rest should be parsed quite well and contrary to HaiQ you would still see the hierarchy of your project, not just a list of files (which matters a lot to me and I'm willing to bet I'm not the only one...).

Another point I'd like to underline is that I could at any time (if I get requests...) add this parsing approach to Edyuk without dropping the current one (yeah I'm quite proud of my project management system ) and let users choose which one they like

[wysota]

Have you tried?

I have a project entry like so:
WWWIDGETS = QwwColorButton QwwColorComboBox QwwConfigWidget \
QwwHueSatPicker QwwHueSatRadialPicker QwwLineEdit \
QwwListWidget QwwLongSpinBox QwwNavigationBar \
QwwNumPad QwwRichTextButton QwwTaskPanel \
QwwTextSpinBox QwwTipWidget QwwTwoColorIndicator \
QwwFileChooser QwwCoverFlowView

And then there are many constructions that operate on WWWIDGETS variable, generating proper HEADERS and SOURCES contents as well as installation targets, etc. So it probably won't work (yes, I use "for").

[magland]

I'm happy that wysota has had some success with haiq, and I encourage him and others to continue following the current development.

But back to the original topic of this thread, I think the best way we can all collaborate effectively using open source, is to make sure our components are generally useful, and not tied to our specific project. I know I can improve on this with haiq, but I really like how Qt source is nicely organized that we can borrow components without grabbing more files than is absolutely necessary. For qmake-haiq, I litterally needed to borrow no more than 3 header file and 4 source files from Qt! This, I think, is a worthy goal to pursue when programming in open source. I.e. pay attention to the dependencies.