Right, this can be easily implemented in your own script, so I don't see how this could be a feature of KDevelop. In fact this could work even without a running kdevelop, in that case you can start kdevelop and load a file into it using dcop.

Also files that are part of your project can easily be opened with the quick open dialog, IIRC the default shortcut is Ctrl+Alt+O (or +Shift, not sure).

I'm tempted to close this as invalid, but I'll leave it open to get some more comments from other developers.

Who likes to write scripts for such a thing? That's not comfortable. And how can you make sure that the file is opened in the right kdevelop-instance?

I think a better integration of konsole would be great.

- You could type "open <filename>" to open a file that is not in the project

- You could type "someStrangeVersionControlProgram diff | open" to show an arbitrary diff within kdevelop

- even cooler would be if you could type "build" in a subfolder of your project so that subfolder would be built using the build-system manger

- Cool would also if you could type "parse make bla" so you could build the project in some custom way from the console, but the output would be parsed by the make-output-widget within kdevelop.


Especially the last two would make my life easier.

Implementing it would not be that hard. Important would be that kdevelop sets in environment-variable in the konsole that would allow identifying the correct instance of kdevelop with dbus/dcop.

Then a few scripts could be supplied with kdevelop like kdevelop_parse, kdevelop_build, and kdevelop_open, and one script that would be called at each start of a konsole-session within kdevelop that would be run to set the bash-aliases "open=kdevelop_open", "parse=kdevelop_parse" and "build=kdevelop_build", and to give some initial output to inform about those commands.

Sounds very realistically doable to me, but for kdevelop-4 not for 3. :)

Some other ideas:
- You could call "debug ./myotherexecutable myargs" in the console to debug an executable in kdevelop(this is much faster than changing debugger-options from the menu)
- The make-output-widget could automatically detect whether the console contains make-output and automatically parse it into a new tab

Better command-line interoperability might help some people to slowly move away from konsole/emacs to kdevelop. :-)

I disagree here. Somebody who wants an IDE shouldn't need the embedded konsole except for rare cases. If people need it more often then somethings wrong with KDevelops UI.

The run/debug argument is kind of weak, KDevelop4 will be able to let you have any number of runnables.

The only thing that does make sense to me is the build thing, although I don't use the features of the make-output-widget in KDevelop3 myself I can see how that is useful.

As far as open goes, well we could add support for single-instance KDevelop and opening files given on the commandline. Then you'd just do kdevelop foobar.cpp hi.h bubble.java and they show up in the active mainwindow of the running instance. I think I'd prefer that.

It's a fact that many people are familiar with the console, and use it a lot. I am one of them. 

Maybe the reason is that kdevelop really has some limitations, but we cannot expect kdevelop-4 to be perfect from the beginning, and even if would be perfect I'd probably still sometimes use the console, it's simply more versatile than any IDE can ever be(though an IDE is more comfortable).

I'd also like kdevelop to be usable on projects that are not imported into kdevelop, as a utility that makes a programmers life easier, without forcing him to setup a project before he wants to change just a line of code and compile.

Just think how easy this would be:
svn checkout https://someIntersetingNonKdeProject
cd trunk
open buggyFile.cpp  
#edit a few lines to support your hardware or something
make  
#get the output parsed by kdevelop, jump to your syntax-error using f4, repair it
make 
#ready

That's so comfortable, even a console-hacker would love it. :)

Now think how much work it would be doing this with kdevelop-3.4. You'd probably prefer kate for doing it.

So I think such commands would be very useful, and given how easy that would be to implement with the right dbus interfaces in place, I don't know why we shouldn't do it.

Well, building a non-project hardly will work, as our interfaces are tied to projectfileitems and the build interfaces don't provide any way to build an arbitrary directory. One reason for that is project items may contain extra stuff that is needed to build in a certain dir. Anyway, deeper discussion of this topic should happen on our mailinglist and preferably at a point in time where we actually have dbus interfaces ;)

*** Bug 60535 has been marked as a duplicate of this bug. ***

This is possible now, to some extent.

Type "help!" to see what you have available.