Another note about kdev-python branches

There’s now a 1.3 branch in kdev-python which is compatible with kdevelop 1.3 beta (the 1.2.82 or so tags). If you want to use kdev-python, please use this branch.

The current master branch uses some functionality which has not been added to kdevplatform yet, and thus won’t compile unless you apply a patch. I’m sorry for breaking it, I’ll try not to do that any more in the future.

Update:  As of 01.03.2012, I reverted the breakage (I should have done that immediately… well, next time). The patch which caused it is to be merged soon, so I can revert the revert to deliver a long-overdue bugfix then. 🙂

Update: As of 06.03.2012, the required changes were submitted to kdevplatform and this issue is now completely resolved. This change should vastly improve the “I need to refresh the file manually in order to get correct highlighting” issues you might be experiencing.

Categories: Everything

9 replies

  1. Love you plugin. I was just wondering what is the planned schedual release. Right now I found an odd bug. The plugin get's into a state that the only way to position the cursor is to use the mouse. I was only able to get out of that mode by restarting kdevelop4.

    Does the plugin allows one to run and debug python within kdevelop4 environment. At this time I don't see how that can be done?

  2. The bug you found is unlikely to have anything to do with this plugin… you might want to test that by disabling it and then trying if it still happens. Sounds more like a kate / kdevelop bug to me…

    Running applications is possible, just go to Run -> Configure launches and add a new launch configuration, set the type to "script application" (in the left treeview) and enter python as the interpreter. Debugging doesn't work yet; debugger support is planned, tough. There's even a branch with debugger support, but it only allows you to step forward through your code, it's quite pointless ;P

    There's no fixed release schedule. The only schedule is "as soon as possible", but that might well take another month or two, or even more.

  3. Thanks, for the information about running the python program and I am looking forward to the debugger directly in kdevelop; right now I use eric at work. I would eventually like to use Kdevelop4 for all my software development.

    as to "…Kate/kdevelop bug…" I have used kdevelop4 to do all my python coding for the past 4 months. I did not see the problem until I installed the PYTHON plugin and started to use it (I really do like using it) so I doubt if it is a 'Kate/Kdevelop4 bug. I will see if I can readily replicate the problem.

    Thanks again
    PS: Is there place other than your blog you would want me to post issues?

    • Yes, please post bug reports on bugs.kde.org (select "kdev-python" as the product).

      I once had a similar issue to what you described, which was solved by completely un- and reinstalling kdevplatform and kdevelop. Maybe it helps for you, too (if you're able to reproduce it at all).

  4. Did you see this new compile bug just introduced just by doing
    git pull on the latest

    Linking CXX shared library ../lib/libkdev4pythoncompletion.so
    [ 82%] Built target kdev4pythoncompletion
    [ 85%] Building CXX object
    CMakeFiles/kdevpythonlanguagesupport.dir/kdevpythonlanguagesupport_automoc.cpp.o
    [ 87%] Building CXX object
    CMakeFiles/kdevpythonlanguagesupport.dir/pythonlanguagesupport.cpp.o
    [ 90%] Building CXX object
    CMakeFiles/kdevpythonlanguagesupport.dir/pythonparsejob.cpp.o
    /home/XMan/Documents/Projects/kdevelop4/src/kdev-python/pythonparsejob.cpp: In
    member function ‘virtual void Python::ParseJob::run()’:
    /home/XMan/Documents/Projects/kdevelop4/src/kdev-python/pythonparsejob.cpp:142:84:
    error: ‘ownPriority’ was not declared in this scope
    make[2]: *** [CMakeFiles/kdevpythonlanguagesupport.dir/pythonparsejob.cpp.o]
    Error 1
    make[1]: *** [CMakeFiles/kdevpythonlanguagesupport.dir/all] Error 2
    make: *** [all] Error 2

  5. Imho now it is a perfect opportunity to release a tarball (even if you call it beta or even pre_alpha). New KDevelop is close (you could do a side-by-side release with that), master is too experimental to use, think about it. This will give your plugins the chance to hit distros repos, and get more testing (and possibly new contributors). Still, the final decision is yours of course, I'd wanted just to point out that as a distro packager I'd be glad to see it hitting my distro's official mirror finally (even hardmasked):D

    • Hm, yeah… but this thing which is broken in master is actually a bugfix for something that has been broken before ;p

      I'd really like to do a release (even unstable, as you say) as soon as possible, but there's simply things left which do not work properly (not fancy features, but very basic things), and which will likely yield thousands of frustrated users writing angry bug reports. 🙂

      I'll think about it, tough. Thanks for the suggestion.

  6. i count day's for release your plugin , and i need that .
    no good ide for python ,
    but i think KDevelop+your plugin is exactly what i want
    i compile Kdevelop and test your plugin … i think it is great

Leave a Reply to Anonymous Cancel reply

Your email address will not be published. Required fields are marked *