I just discovered Planet KDE and immediately got addicted. Planet GNOME was one of my favorite readings on the web the last months, but I think I have to switch now. 
It's great to see that there is a Planet KDE, but why didn't this information come through earlier? Well, the dot is down. The other question is why the blogs from kdedevelopers.org aren't on the planet. Clee blames Ian. So Ian, stop fooling around with Windows programs and fix the feeds, please.
Recompiling kdepim again. It's not that much fun without proper icecream support, but it leaves me some time to write a blog entry, so that's not entirely bad. The annyoing thing about writing blogs is the clumsy web interface of kdedevelopers.org, so earlier today I tried to get an overview about blog tools. The only result was that I got completely lost. I hoped for the one and only tool which perfectly fits all my needs. What I got was a collection of strange scripts I don't understand and some unfinished apps. So what do people actually use to write their blogs?
Syndicate Blogs
kblog
was at one time hard coded to work with drupal... its in kdenonbeta and needs help. the bloggerapi connections used to work, so its just an issue of cleaning up the UI. i mainly lost interest because KRichtextEdit was too under powerd and KateTextEdit was too hard to use.
KBlog and WordPress
Ian,
What would it take to add WordPress support to KBlog? I was going to look at KMT which uses the MoveableType API (WP supports that) and see if I am able to extend it and update it, but the source seems to have gone MIA.
Hmm, I should look at the KBlog source...
if its...
using XMLRPC on the back end, then KBlog will work with it with only minor changes. The goal was to have multiple back ends, but this is a horribly mutated version of a small one off i wrote for my wife to post to her blog.
XMLRPC, WordPress, and KBlog
WP does indeed use XMLRPC. What would be the next step for me?
Wonderful...
.. and I've been waiting for it for a long time. Any RSS feed for it? It'd like to add it to the default feed list of kdenonbeta/akregator
Yes, there is an RSS feed...
As a matter of fact, there is!
It's a stock-standard planet installation, but it's not quite finished yet. I probably should have put some sort of access control onto the page, but I'm too lazy.
You can grab the RSS 1.0 feed from http://planetkde.org/rss10.xml and if you're into RSS 2.0 for whatever reason you can use http://planetkde.org/rss20.xml as well.
There's a foafroll and an opml file as well, at foafroll.xml and opml.xml respectively.
I've got to tweak the sidebar on the page with the disclaimer and such too... maybe that'd be a good thing to take care of tonight.
Hopefully geiseri will fix the RSS feed tonight too, so that I can turn on all of the blogs from here.
I suddenly realized
that planetkde was getting pretty popular, since posting a single image in my blog immediately sucked up all my bandwidth -- would it perhaps be possible to fix the planet code so that it doesn't show the full article, but only the intro. Blosxom has this feature where when you put a <!--more-- > in, it splits the article in an intro and a full page view...
I've got a temporary fix for now...
I have the CSS setup so that any images in the blog contents have the property display: none;
This has the neat effect of allowing all of the regular images to work fine and reduce the load on your server.
It'd be more elegant if I could replace the images with text instead, but hey, this works for now. If someone else comes up with a better solution, please, by all means, let me know.
Boudewijn, the traffic to your blog should be much reduced now.
Thanks!
(I wonder why not all my comments show up... -- I answered myself that I discovered that blosxom's rss feed doesn't sent out the separation marker and that I would have to hack blosxom, but I see it hasn't appeared in this discussion.)
A better idea would probably
A better idea would probably be turning all embedded images into links on planetkde.org, this would allow everyone to read all full articles without needing to follow links while long loading time due to possibly huge images one might not be interested in (as well as sucking all the bandwidth of the article poster) is avoided.