Before everything else, I want to send a big “thank you” to our hard-working sysadmins who spent so much time and effort recently on fixing the git servers! It’s working nicely again.
Other than that, there’s various news in kdevelop-land: kdev-python now has a branch which builds against upstream python 3.4 (which is not released yet), there’s a few fancy new features in kdev-qmljs (QML / javascript language support for KDevelop), and KDevelop has a new splash screen.
kdev-python without modified Python fork
Until now, kdev-python’s repository contained a fork of Python. This fork was modified from the official version of Python to fix some issues which were counteracting its use as a parser in an IDE. Fortunately, a patch of mine now was accepted upstream which solves most of the issues, so in the future, the fork will not be necessary any more. Unfortunately tough, the patches changes are not binary compatible, and thus will only go into the next feature release of Python (3.4), and also cannot be backported. This means that the Python 2 version of kdev-python will have to stay with the fork.
This also means that plans for Python 3 in kdev-python support have changed: since I don’t want to maintain three versions (python2, python3 with fork, and python3 without fork) the official release of kdev-python3 will have to wait for the release of Python 3.4 (early 2014). I’m sorry. If you need it, either build the (now unmaintained) python3 branch, or build Python 3.4 from mercurial and build kdev-python’s python3-nofork branch against that. Alpha releases of Python 3.4 are going to happen soon-ish, you should also be able to build against those.
Apart from this local (in time) trouble however this is great news for kdev-python — it’ll make it much easier to maintain and adjust to future releases of Python, also it’ll be easier to package, use less memory, and less disk-space (one can question the relevance of the two latter points of course 😉
New features in kdev-qmljs
After all that dry and difficult hacking on python’s and kdev-python’s AST, I wanted to do something fancy. So, I made this:
 |
| Inline color picker in kdev-qmljs |
It should be rather self-explaining what it does. It needs a slight change to kdevplatform, so you need to update that too if you want to try it. I also made similar popup widgets for a number of other things in QML too:
 |
| Inline popup widget for modifying item spacing |
Those widgets always show a generic preview image and allow modifying a property with a slider or similar. They’re written in pure QML, so it’s easy to add more widgets for other properties (adding a new widget currently requires a one-line-change in C++ tough, this might be useful to change in the future to make it easy for users to add their own widgets).
I know that the usefulness of those is questionable. The color picker is useful for sure, but about the rest… I don’t know. It seemed like a good idea, so I tried it out — opinions, ideas and other feedback is welcome.
Oh, the color picker currently doesn’t work with alpha colors, I know, I’ll fix it some day.
New splash screen for kdevelop
Another thing which was a victim of my “I want to do something fancy” streak was kdevelop’s splash screen. It’s now also written in mainly QML, and gets progress info from kdevplatform. It looks like this:
 |
| KDevelop’s new splash screen. |
The progress steps might need a bit of work. The timing is not accurate here, I had to pick few frames to get a reasonable file size.
Oh also, look what awesome old splash screens you can find in the current kdevelop repository:
 |
| Actual picture! |
Categories: Everything
Tags: kdev-python, kdevelop, planetkde
This is amazing! Thanks a lot for your hard work!
Although the previews may seem gimmicky, it's still a great way to give the programmer a sense of how something will look, without recompiling 🙂
Thanks 😉
QML isn't compiled tough, so if you did it correctly, you might get a "real" live preview. I'm still thinking about whether that would be doable in a general case.
It would need to be guarded against slowness tough, so it doesn't crash (or slow down) the IDE when you type something like while ( true ) { }…
Ehy, I remember that splash screen 😀
Oh, that looks like a proper IDE not like plasmate.
On that matter, I'm personally very sad that plasmate is not based on kdevplatform. If it was, we could have shared the language framework and also features like this one — it would have helped kdevplatform, and plasmate too 🙁
After all, kdevplatform is being kept seperate from kdevelop for exactly this purpose — creating another IDE which has a different UI but needs the same features (language support!) under the hood.
Nice widgets! Could you include a 'last chosen colors' pallet and maybe a 'replace all occurences of old color' button? Just to make it workflow perfect 😉
Sure, I can do that later — if you don't want it to be forgotten, report it on bugs.kde.org as a wish for kdevelop and assign it to me 😉
Have you got any links to the relevant bugs/peps/commits in Python required for the no bundled Python and are they _binary_ incompatible or _api_ incompatible?
Specifically, having a bundled library is a huge problem for several distributions (security/maintenance/tracking/etc). If the changes are only binary incompatible then it is very easy to workaround with a rebuild of a patched version of Python and any native Python modules. If it is api incompatible then it depends very much on the extent of the incompatibility.
The changes are source incompatible, and will likely need adjustment if you want to backport them to python 2. The incompatibility is not too significant, it would only affect software using the AST API, which most programs don't do. If you use the AST API from python, it might break too, if you were constructing ASTs and compiling them then (here, too, I'm not sure if anything uses it). The most likely kind of software you'd run into trouble with would be something like rope.
This is the relevant bug report at python: http://bugs.python.org/issue16795
I'm aware that this is a problem for some distributions, and I'm sorry, but there just wasn't a better option at the time being. I'm looking forward to python 3 taking over, so we I can finally leave the fork behind completely. If a distribution has problems with packaging it, my advice would be to just not package the python2 version for now and make sure there's up-to-date kdevelop and kdevplatform packages available — it should be easy to compile for users then.
However, as discussed in much length on kde-core-devel, not many of the usual security/maintenance arguments apply in this case — python 2.7 is pretty much frozen, especially the part which kdev-python uses. I don't know of a single security or memory issue since 2.7.0 which would affect kdev-python, and I doubt any will appear in the future.
Ah, and I forgot: this is for the patch now applied to upstream. The way it's done in the 2.7 fork is different; it's more hacky and generally worse, but it keeps source compatibility. If you wanted, you could probably apply these changes to a distribution's python without causing issues (binary compatibility would still break, though, as properties are added to public structs). The only thing you'd get would be more accurate error messages 😉
Realistically though, including the fork is the less risky variant by far in my opinion. Remember, the fork is only used for parsing, the interpreter itself isn't even built, and nothing of the compile/execute parts of the language are in use.
No need for the apology. These things are required sometimes. I mainly wanted to weight the the bundled library exemptions (requires going through a committee etc) and related maintenance costs against carrying a few temporary patches which is not unusual anyway so long as it's not too intrusive. Worst case is the package does not get into the distribution until Python 3.4.
Thanks for the info though. Now I can look at the effort required to get this into our Python 3.3 build and otherwise your info on the very limited use of the embedded Python fork will help tremendously in getting a bundling exception.
Thanks again and keep up the good work 🙂
Getting the changes ported to python 3 should be easy. But, if you do that, you can only run the python 3 version of the plugin against it: python is used for parsing, and the version 3 release of python cannot parse python 2 sources, so the plugin cannot analyze them. The python 3 version of the plugin is currently unfinished and has not yet been released (mainly since I have to wait for the upstream release to officially release it anyways). So, I'd go as far as saying that porting the changes to python 3.3 doesn't really buy you anything 🙁
Thanks for your efforts with packaging this!
… *ported to python 3.3, I meant to write.
If you want to discuss this further, we can of course do so here, but please feel free to write me an email or ping me on irc.freenode.net too if you'd prefer that.