I’ve just released the KDevelop Custom Buildsystem version 1.2.2 suitable for usage with KDevelop 4.4/KDevPlatform 1.4. There have not been many changes, mostly just adaptions to KDevPlatform API changes. The only real new feature is the ability to filter our version control directories like .git or .svn.
Downloads can be found on the KDE download server. Hashsums for the package are:
MD5Sum: a5a26833510281a962d0b68296fce7cd kdevelop-custom-buildsystem-1.2.2.tar.bz2
SHA1Sum: e24fcd9f98c13a9043a00c941fd3ab11ba60fc03 kdevelop-custom-buildsystem-1.2.2.tar.bz2
This will probably be the last separate release of the plugin, I plan to move the code into KDevelop for the KDevelop 4.5 release.
Today the repository for the Custom-BuildSystem plugin moved to git.kde.org. So you’ll have to adjust your remote urls accordingly. The right url can be found easily on the new project page of the plugin. I’ll delete the gitorious project sometime next week so people are not getting confused too much.
Its been quite a while since I blogged, but this is really worth it.
I was talked into doing a first release of a KDevelop 4 plugin I’ve worked for some time now (thanks Milian 😉 ). There’s been already a blog entry about it before that highlighted the features the plugin has and what its intended use is. Just a quick recap: It allows to setup executables to be run for build/configure/install/… and configure include paths and defines per build directory so that projects using something other than make/cmake/qmake can be nicely worked on with KDevelop.
Additionally it now properly supports multiple build-directories and switching between them by making sure that the language support is re-parsing the project to update the data based on the new includes. I’m using
that now quite a bit to switch between my Qt3 and Qt4 build dirsectories.
Reporting bugs has also been improved by re-using KDE infrastructure instead of mailing me directly which I almost always forget about… So in case you do find a bug or have a feature suggestions, simply file a bug against kdevelop (if possible directly choose the “custom-buildsystem” component in bugzilla) and I’ll try to take care of it.
The source code is currently still hosted on gitorious.org but will move to git.kde.org soon. I just wanted to have a release out in the wild to demonstrate my willingness to maintain this plugin and hence be able to move to the stable-plugins subproject within KDevelop (yeah they setup rules for that 😉 ).
You can find the source code on any of the KDE mirrors and here are the hashsums to verify you’ve got the proper package:
MD5Sum: 2d373002ddac5f5c23f67620bcbcc63d kdevelop-custom-buildsystem-1.0.0.tar.bz2
SHA1Sum: 25e08a67f653eae5210ad360c7cb559b2178e0cd kdevelop-custom-buildsystem-1.0.0.tar.bz2
I’ve switched away from konqueror about half a year ago as the amount of sites that weren’t working quite properly became too many and too important (like our internal wiki and ticketing at work). Konqi was also getting kinda slow back then. I never had the time and energy to pursue any of the problems as switching to something else was simply much easier and less time-consuming. Since then I’ve used Chrome, but I’ve always missed some things like kwallet-integration, re-using my existing konqi-bookmarks and it annoys me that it installs a deb-repo without asking.
After having read and heard quite some good things about rekonq I decided to try it out yesterday. And basically I’m sold 🙂 It renders the pages I’m using regularly properly (as its also webkit under the hood), it supports my web-shortcuts (and I didn’t have to set them up to begin with), it reads my old konqi bookmarks and also has the developer-features. There are only 2 things keeping me from switching to it as my default: It only runs on 1 out of 3 machines as it needs Qt4.6, this is something that’ll be resolved over time. And it currently has an annoying behaviour that gives me an error page if some http-request fails, even if that request was made from an iframe, which completely breaks using it with our ticketing system (bugreport filed already).
So yeah, I’ll keep a close eye on rekonq as I’d really love to switch back to a kde-based browser – I even already wrote a chrome-json-bookmarks to xbel converter to get my chrome bookmarks back into kbookmarks.
Yeah, thats right, I just replaced the original repo content on gitorious.org via a forced-push with a newly generated repo. This was necessary as I missed a conversion-error from the svn2git rules earlier which screwed up the checked-out content of the repository.
I’ve decided to do a forced push instead of trying to fix up things manually as only few (if any) people have a checkout of the repo currently and those that do should be able to follow the below steps to fix their local clones.
Basically all you need to do is fetch the changes and then reset your master branch to the new origin/master commit. This can be done by using:
git checkout master
git reset –hard 0b8e32f7955665cbbab4b297c464857b477b877b
If you had local branches before, then for each of those local branches the following should work to apply them against the new master (didn’t test that though):
git checkout localbranch
git rebase master
I hope this doesn’t cause too much trouble for anybody.
Wow, I haven’t blogged this much in quite a while…
This will be a relatively short announcement that kdevelop, kdevplatform, quanta and the two php plugins have been moved to gitorious.org. This will allow us to work on features more easily and hopefully also help us get the next release finished before another 2 years passed by 🙂
So if you’ve checked out KDevelop&Co from Subversion trunk/extragear/sdk then please look at the above link to find the respective git-clone urls. The compilation instructions stay the same otherwise.
I’ll be deleting the svn account in a few minutes and replace it with README’s pointing everybody here.
Those reading the dot regularly will already know it, the final release of KDevelop 4.0 is out. For more extensive information what it includes I suggest you read the dot story.
It only took us 3 years to get there and I think what we’ve accomplished is quite amazing. And its just the beginning, we have various ideas how to further continue with KDevelop and bring you even more cool features and improvements. As I already blogged there’s two GSoC project with much potential related to KDevelop.
Google just announced the official and final list of accepted students for the SoC program. KDE got more accepted students this year than past, so its a big success for us all. This will hopefully again be a successful SoC season for KDE, bringing new contributors and implementing lots of cool ideas.
The KDevelop team got its share too, 2 students will work on the codebase. Aleix Pol is going to improve the community integration in KDevelop, targeting things such as easily finding the communication channels, easily getting the source and contributing patches back to the community. The other is improving the Quanta codebase (that is based on KDevPlatform like KDevelop) to bring it closer to a first release, this will be done by Milian Wolff. This is a very important SoC project for all of KDE as it’ll revive a very successful KDE3 app and the voting clearly showed that there are many people missing it badly.
I’m looking forward to the coding period and the results and hope that I’ll enjoy this SoC as mentor just like the past ones.
This blog entry is a supplemental to the KDevelop 4.0 release announcement to show off the new stable release with some nice screenshots. So enjoy 🙂
This time around svn got me, I’ve used the createtarball script from kdesdk to generate the RC2 tarballs so we ship translations. This worked just fine, except that for some unknown reason svn likes to not check out svn:externals when doing an svn co of kdevplatform.
This resulted in a kdevplatform tarball (yes I didn’t test-compile them as it was rather late already) that didn’t contain the expandingtree subdir in plugins/quickopen.
As (silently) updating 2 days old tarballs has proven to be a bit problematic in the past, I’ve decided to just push in another RC which fixes exactly this problem.
So tarballs for a working fresh RC for kdevelop and kdevplatform should be available from the mirrors in a few hours (and yes, this time I’ve built them on 3 systems to make sure they work).