Posted by
HeUnique
on from the good-progress dept.
I just got the message - Kdevelop 1.1 is out, along with KDK (KDE Development Kit), Kdbg (KDebug 1.0.2) and other goodies for you to enjoy. Also, Martin Konold from the KDE development team sent some pictures from CeBit - worth a look.
I'm a big fan of the KDevelop project. However, one request I would make is to have customizable code-editing widgets. KWrite is a nice widget to use, but it is simply notepad with colors -- not very many advanced features for the seasoned hacker.
If someone could hack vim into a Qt or KDE widget, for use in KDevelop or stand-alone, then I would be impressed. Such a task seems more than trivial, now that I've tried it, because it seems the vim code is not exactly event-driven (or so I gather from some vim developers.)
Nice interface but....the debugger
by
Fnord
·
· Score: 4
This looks fairly nice, I haven't tried it personally but if its as close to VC++ as they say it is then its probably a decent interface to program in. I won't use it though. No matter how nice they make the editors/class browsers/project managers all these ides seem to slack on the debugger. They always have what looks like just a little arrow in the source window that follows the output of gdb, maybe a table of variables, maybe breakpoints. Nothing else. No real use of the power an integrated environment like this COULD give them. The best debugger I have ever used (on any platform) is the Data Display Debugger. I've made a few converts to unix just by showing people what this thing could do. And no I'm not affiliated with the developers of this in any way, I just like the thing. So for me it's still going to be vim/xemacs (depending on my mood) ddd and a makefile for my devel environment.
I downloaded the beta of Kdevelop 1.1. Kdevelop will make people coming from a Windows and VC++ environment really happy, since it offers a similar style of programming and GUI design. Kdevelop will also attract a lot of developers to the Qt toolkit, since it makes it pretty easy to use Qt.
Of course, I'm not entirely sure why this is a good thing. GNU&Linux wasn't built or used by people who approached programming that way. Is KDevelop going to bring a lot of developers from Windows to Linux? What kind of changes will they want in Linux? And what will that mean to the traditional GNU&Linux communities?
I think there is a lot of interesting stuff to be done in the traditional text-based GNU/Linux/UNIX approach to programming. Here are just some simple ideas:
a working command line version of cextract for C++
a better version of make that determines and manages dependencies among C/C++ files faster, more automatically, and more reliably than existing approaches
a constraint and rule-based language for specifying GUIs in your favorite toolkit
an SML-style module system for C (and maybe C++), integrated with a make-like facility
integrating the C/C++ bounds checking hacks into the main branch of GNU C and figuring out a good way of making that backwards compatible with old libraries
KDevelop is glitzy. It's a big and impressive development effort. It's probably useful for people who want to build Windows-like applications with a Windows-like IDE. I can even see why people have fun developing it.
But, ultimately, KDevelop looks foreign to me in a UNIX environment and less useful for traditional UNIX uses and users. I'd like to see more effort go into building tools in the traditional UNIX style (and I'm trying to help when I can).
Great for non KDE development also
by
_Gnubie_
·
· Score: 3
First of all - Thank you to the Kdevelop team!. Kdevelop is imho KDE's killer app. I havent used it to program one line of C++ or KDE code, all of my code is C (openGL stuff and believe it or not I load my Glade generated code into Kdevlop for easy GTK hackng). I have OpenGL and GTK docs available in HTML format in the IDE at the simple click of a button and its easy to add more in the doc toolbar. Kgdb is a excellent frontend to gdb. It lets you view structs in a tree form (Invaluable for linked lists etc etc).
Even if you dont use KDE its worth installing the libs just for this one app
Qt IS an option, but you've got other good ones...
by
Svartalf
·
· Score: 3
Qt (NOT KDE) is an option (and a good one at that) for your work. One should be aware that the should you produce something commercial in any way shape or form, you owe Troll something like ~$1500US- and I can't remember if the Free QT license ammended the rule such that the Windows version was free for GPLed works. If it hasn't been, you'll need to pony up (and anybody else that works on it) ~$1500US to do it.
Other equally good options include GTK+, GTK+/GTK--, GTK+/WxWindows (WxWindows would use the native Windows calls under Windows...), and Fltk come immediately to mind as likely cross-platform GUI apis.
-- I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
KDevelop can be used to develop anything from KDE apps to daemons. Personally, I have only used it for non-graphical applications, and I have found it to be quite good. The Class browser is excellent, and it certainly aided me in farmiliarizing myself with the code in an already in-progress game. (adonthell.linuxgames.com)
I am developing the combat engine in KDevelop, and I have found it first class.
I won't argue with your bulleted points, just the foul smelling bits at the end. I use vi extensively, and mostly run on a command line in Linux. To say that someone using a GUI to get a job done is 'not in the UNIX style' is hog wash.
Do you really think that working with your graphics card in text mode makes you a *real man*, and a true UNIX developer?
You are shooting down a straw man: nowhere did I say that development from within Emacs was more "manly" or that you could only develop graphical applications in KDevelop. In fact, if KDevelop were only for graphical applications, it wouldn't much interest me who uses it.
What I'm saying is that different people have different preferences and styles. KDevelop may well be enormously productive for you and the majority of programmers (just like VC++ is). But for me (and at least some other people), it's just not a good tool (believe me, I have tried). That doesn't mean either way is better than the other, it means that there are different groups of people with different skills and preferences. Just like command line users ought to admit that GUI-based development tools are useful to some, the reverse ought to be conceded too.
What is an open question to me is whether the two kinds of styles can co-exist in the same community. Will I be able to make sense of, and contribute to, your libraries developed in KDevelop using my programming tools? Will you be able to handle modifications that I make to them outside KDevelop? I have dealt with MFC by hand, moved software packages back and forth between VC++ and the command line, etc., and I'm not that optimistic in the long run.
Tools like VC++ and KDevelop tend to encourage much of the intelligence to move into the development environment, making the actual code difficult to read and maintain any other way. And, conversely, tools like VC++ and KDevelop tend not to be able to make a lot of sense of interesting abstractions implemented "by hand".
Maybe my concerns are unfounded: KDevelop, KDE, and Qt are a lot cleaner than VC++ and MFC, and KDevelop tries to fit in well with the current Linux development styles (in fact, I'd much rather use KDevelop than VC++). But I'm not convinced that in the long run, this can work out.
So, Linux may well split into a Windows-like community and a UNIX-like community, with less and less code sharing between them as time goes by. That's probably still better than a MS Windows/Linux split, but maybe by thinking about it ahead of time, we can at least make such a transition easier and have realistic expectations.
Tools like VC++ and KDevelop tend to encourage much of the intelligence to move into the development environment, making the actual code difficult to read and maintain any other way. And, conversely, tools like VC++ and KDevelop tend not to be able to make a lot of sense of interesting abstractions implemented "by hand".
Take a closer look at KDevelop. Don't let it's superficial appearance fool you into thinking it's a VC++ clone. It is not. (tree on left, view on right and messages below actually makes sense).
Beneath it all, KDevelop uses exactly the same tools you are: g++, make, autoconf, etc. No, its makefiles are not the most readable in the world, but that's an artifact of the autoconf schema, not of KDevelop. And unlike VC++, it won't try to write your classes for you. Other than the brief application "template", which you can easily replace, it does no coding for you. If you have it create a new class for you, it creates an empty one. KDevelop is essentially an editor, class browser, documentation browser, dialog editor and debugger, all rolled up into one with a ton of documentation thrown in to boot. It's not trying to change how you program, like VC++ does, but instead is trying to give you all the tools you need in one package.
No, the editor doesn't have the power of emacs. So what? For some people, this is actually a plus. And the debugger isn't as rich as ddd, and the dialog editor isn't as full blown as QtArchitect, etc. That's not the point. The point is that KDevelop has a whole bunch of good tools integrated into one IDE.
-- A Government Is a Body of People, Usually Notably Ungoverned
Slashdot Mirror
I'm a big fan of the KDevelop project. However, one request I would make is to have customizable code-editing widgets. KWrite is a nice widget to use, but it is simply notepad with colors -- not very many advanced features for the seasoned hacker.
If someone could hack vim into a Qt or KDE widget, for use in KDevelop or stand-alone, then I would be impressed. Such a task seems more than trivial, now that I've tried it, because it seems the vim code is not exactly event-driven (or so I gather from some vim developers.)
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
This looks fairly nice, I haven't tried it personally but if its as close to VC++ as they say it is then its probably a decent interface to program in. I won't use it though. No matter how nice they make the editors/class browsers/project managers all these ides seem to slack on the debugger. They always have what looks like just a little arrow in the source window that follows the output of gdb, maybe a table of variables, maybe breakpoints. Nothing else. No real use of the power an integrated environment like this COULD give them. The best debugger I have ever used (on any platform) is the Data Display Debugger. I've made a few converts to unix just by showing people what this thing could do. And no I'm not affiliated with the developers of this in any way, I just like the thing. So for me it's still going to be vim/xemacs (depending on my mood) ddd and a makefile for my devel environment.
here is a mirror of the pics: http://squadron.org/CeBit/
Of course, I'm not entirely sure why this is a good thing. GNU&Linux wasn't built or used by people who approached programming that way. Is KDevelop going to bring a lot of developers from Windows to Linux? What kind of changes will they want in Linux? And what will that mean to the traditional GNU&Linux communities?
I think there is a lot of interesting stuff to be done in the traditional text-based GNU/Linux/UNIX approach to programming. Here are just some simple ideas:
KDevelop is glitzy. It's a big and impressive development effort. It's probably useful for people who want to build Windows-like applications with a Windows-like IDE. I can even see why people have fun developing it.
But, ultimately, KDevelop looks foreign to me in a UNIX environment and less useful for traditional UNIX uses and users. I'd like to see more effort go into building tools in the traditional UNIX style (and I'm trying to help when I can).
First of all - Thank you to the Kdevelop team!. Kdevelop is imho KDE's killer app. I havent used it to program one line of C++ or KDE code, all of my code is C (openGL stuff and believe it or not I load my Glade generated code into Kdevlop for easy GTK hackng). I have OpenGL and GTK docs available in HTML format in the IDE at the simple click of a button and its easy to add more in the doc toolbar. Kgdb is a excellent frontend to gdb. It lets you view structs in a tree form (Invaluable for linked lists etc etc).
Even if you dont use KDE its worth installing the libs just for this one app
Qt (NOT KDE) is an option (and a good one at that) for your work. One should be aware that the should you produce something commercial in any way shape or form, you owe Troll something like ~$1500US- and I can't remember if the Free QT license ammended the rule such that the Windows version was free for GPLed works. If it hasn't been, you'll need to pony up (and anybody else that works on it) ~$1500US to do it.
Other equally good options include GTK+, GTK+/GTK--, GTK+/WxWindows (WxWindows would use the native Windows calls under Windows...), and Fltk come immediately to mind as likely cross-platform GUI apis.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
KDevelop can be used to develop anything from KDE apps to daemons. Personally, I have only used it for non-graphical applications, and I have found it to be quite good. The Class browser is excellent, and it certainly aided me in farmiliarizing myself with the code in an already in-progress game. (adonthell.linuxgames.com)
I am developing the combat engine in KDevelop, and I have found it first class.
I won't argue with your bulleted points, just the foul smelling bits at the end. I use vi extensively, and mostly run on a command line in Linux. To say that someone using a GUI to get a job done is 'not in the UNIX style' is hog wash.
Do you really think that working with your graphics card in text mode makes you a *real man*, and a true UNIX developer?
Come on, you're smarter than that.
What I'm saying is that different people have different preferences and styles. KDevelop may well be enormously productive for you and the majority of programmers (just like VC++ is). But for me (and at least some other people), it's just not a good tool (believe me, I have tried). That doesn't mean either way is better than the other, it means that there are different groups of people with different skills and preferences. Just like command line users ought to admit that GUI-based development tools are useful to some, the reverse ought to be conceded too.
What is an open question to me is whether the two kinds of styles can co-exist in the same community. Will I be able to make sense of, and contribute to, your libraries developed in KDevelop using my programming tools? Will you be able to handle modifications that I make to them outside KDevelop? I have dealt with MFC by hand, moved software packages back and forth between VC++ and the command line, etc., and I'm not that optimistic in the long run.
Tools like VC++ and KDevelop tend to encourage much of the intelligence to move into the development environment, making the actual code difficult to read and maintain any other way. And, conversely, tools like VC++ and KDevelop tend not to be able to make a lot of sense of interesting abstractions implemented "by hand".
Maybe my concerns are unfounded: KDevelop, KDE, and Qt are a lot cleaner than VC++ and MFC, and KDevelop tries to fit in well with the current Linux development styles (in fact, I'd much rather use KDevelop than VC++). But I'm not convinced that in the long run, this can work out.
So, Linux may well split into a Windows-like community and a UNIX-like community, with less and less code sharing between them as time goes by. That's probably still better than a MS Windows/Linux split, but maybe by thinking about it ahead of time, we can at least make such a transition easier and have realistic expectations.