And proper project management with proper buildsystem support is hard. KDevelop3 was very good at that. Anjuta only recently got close to what our Automake manager had for 4 years. My KDE-Eclipse autotools plugin did get some attention by RedHat guys after I stopped working on it, but I don't know what happened next. Seems like "fedora eclipse" project now superseded it. So even Eclipse doesn't have something on a par yet.
This all means KDevelop's features are still unique. Especially unique is QMake manager which has no alternatives I know about. After Andreas Pakulat took my qmake parser and vastly improved the manager in KDevelop 3.4, we can open and manage the most complex qmake project - the whole Qt library (both 3.x and 4.x versions).
But the time doesn't stop and KDevelop development doesn't stop either. We always wanted to change two things in 3.x - make it possible to open more than one project at a time and avoid code and UI duplication between buildsystem plugins.
As for today, in KDevelop4 we managed to realize our plan. First, Andreas Pakulat implemented support for opening several projects at a time. Second, we used Roberto Raggi's project management architecture with one user-visible "Project Management View" which displays information from various build system managers. That all grants the popular wish to open many projects and solves code maintainability and complexity issues at the same time!
You can see the current state of things in the screenshot below where I've opened two QMake projects using QMake Manager and KDevelop4 project using Generic Manager (CMake Manager is not yet ready). Looks cool, doesn't it? ;)
4 comments:
Just noted a little inconsistency in the File Manager.
The little arrows besides the folders suggest that you go to the right in the hierarchy. But the folder at the top points up, which is quiet standard, but a different direction.
What about putting an arrow to the left on the left-side of the folder-view, together with the home-button and leave the room where the current home-button is for user-defined shortcuts?
Agree, the "up" icon is inconsistent. I'm not sure how your variant will look like, but I'll try it.
From the other side, on iPod the navigation is done with "center" and "menu" buttons. And the last one is placed at the top but still has "move left" semantics. In the same way our filemanager allows enter/double click to "move right" and has "up" button to "move left".
Why not doing it similar to dolphin?
Something like:
==================
[H] ... dirA->dirB
---------------------------
file1
file2
...
fileN
==================
... and use QColumnView (if not doing it already)?
We can't use QColumnView atm because is in Qt4.3 which isn't in KDE svn's qt-copy.
But in any case filemanager for KDevelop doesn't have as much horizontal space as QColumnView wants.
As for dolphin's navigation, I like it very much, but again, I fear that lack of horizontal space will make the breadcrumb widget unusable. Dolphin doesn't have scrolling for it, it just shrinks navigation buttons. What do you think if we have something like that for our filemanager but with scrolling?
Post a Comment