KDE Blogs 

kde.me.uk has some things of mine on it. kde.com's e-mail feed of KDE dot news died along with kde.com so I set up another one for dot news and added debianplanet.org and kdedevelopers.org. email news feeds. KDE dot news are planning on adding their own e-mail feed so that one may dissapear. Read More

This week brought a couple of new exciting things to KDE. Having a closer look at what was announced these days I'm pretty amazed. It started with kde-apps.org on Monday, the followup to the highly popular kde-look.org. On Tuesday we got KDEPIM on Mac. Wednesday brought integration of native KDE widgets in OpenOffice. On Thursday we saw a nice interview about Qt styles for Gtk apps and the announcement of KDE ioslaves for FUSE which basically means that they are now accessible by any non-KDE program, OpenOffice only being one of them. On Friday Zack released his QtGtk library which allows to use all the fancy stuff of KDE like the file dialogs or DCOP in Gtk apps. KDE seems to become the integrative desktop. That's good news. Let's see what will happen on the weekend... Read More

For a long time I have hoped that managed code will beat statically compiled code one day. Managed code can make software more secure, CPU-architecture-independent and makes it easier to generate executable code. The only remaining problem is the performance. Theoretically managed code should be faster than native code that the linker does not understand, because of the better optimization opportunities. But in practice and especially in public perception it always trailed behind. The benchmarks published by OSNews suggest that, at least in the commercial space, managed code is already competitive and can beat unmanaged C code. The nice thing about the OSN article is that it's probably the first time that someone was so (stupid|brave) to violate Microsoft's licensing agreement and publish benchmarks for C# - but even Java did very well against gcc. Read More

So, yup, this is my blog entry, and I have no idea what to write about. Maybe it's because I'm not doing anything, or maybe it's because I'm doing too much, or.... and the list could go on and on. Or maybe, it's because I'd like to try fixing Xinerama support, but I haven't a clue where to start, and I went back down to a single monitor a couple of weeks ago because having that second monitor left no room on my desk. :( Anyways, I've rearranged the desk and so now I may try again after I get home. I'm stuck at work right now, and it really sucks since I don't have a whole lot of time to work on KDE here anymore because we're always so busy. :( Maybe it'll slow down some though and I can get back to hacking. Read More

I was talking to Rich today and he pointed me to a wonderful paper : http://www-sop.inria.fr/odyssee/research/tschumperle-deriche:02d/appliu/index.html . Please look at the image restoration one can achieve with this baby. The "Image Inpainting" examples are breathtaking! The whole thing is on my todo for KDE 3.3. I also got reports from people that some effects from KImageEffect simply don't work, or even worse are crashing. As it seems a lot of them hasn't been tested. Read More

Well it has been a busy two weeks. I have been fixing a few bugs in kjembed here and there and pushing its limites with my two scripts... oh yeah i have a new script [Envelope Maker|EnvelopeMaker]. Read More

I'm over at Ian's place at the moment. West Chester, PA, suburbia at its best :) Everytime I come over he makes me do something weird. This time he made me write a bumpmapping algorithm for him. It's mostly used in 3D computer games, since it makes really nice textures. Why did he need it? I'm sure he'll tell you sometime soon in his blog. I'll move the bumpmapping algorithm to kdefx KImageEffect after 3.2. Also if you know any graphics algorithm that you would like to use with QImage's let me know. Either send me the name of the algorithm and the app which implements it, or preferably math behind it. One of my friends pointed me to the following comment by Jamie Zawinski. He says that it's not possible to mix GNOME and KDE widgets. The whole "not possible" thingy never worked too well in Open Source. Hopefully soon I'll release something that proves Jamie wrong. Hold your finger crossed as I'm busy with some other things at the moment. Read More

I've finally completed the C++ bindings for libusb - what a fun way to spend New Years Eve. This implementation is layered on top of the C routines - no changes to any of the existing code, so it should be portable to any platform supported by libusb. It relies on Qt - I looked hard at the STL stuff, but Qt was much better, especially for string handling (yep - USB devices return strings in Unicode). I decided to stay with QPtrList for now, despite being told it wasn't likely to last long - it was a better match for my conceptual design. Read More

There's good news to report today, I added the first autogenerated binding to the CVS last night! The binding provides access to QDir but the tool is generic and should work on anything we can access as a JSOpaqueProxy (this limitation will be lifted later). There are still some rough edges, and the constructor functions aren't autogenerated yet but basically it works. The next step will be to clean things up a little and to add support for default function arguments. This should be pretty simple.

DTDs and everything in the <!DOCTYPE> tag is horrible. The syntax is cryptic, the allowed types are odd and the degree of complexity is very high (parameter entity references!). RelaxNG and even XML Schema are much better solutions, and the XML specification could be reduced by at least 75%. Entity references are not needed in a Unicode world (exceptions: the predefined entities and character references). Processing instructions are an odd and unstructured mechanism for meta-data about the XML and should not be needed anymore, because namespace'd elements and attributes could achieve the same. CData sections may be somewhat useful when writing code by hand, but that does not compensate for the complexity that they add to document trees - without them there would be only one type of text. Different char sets. There's no real need to allow different charsets in XML, it just hurts interoperability. It should be at least restricted to the three UTF encodings, maybe even only one of them. Allowing charsets like 'latin1' is useless if processors are not required to support them. The lack of rules for whitespace handling. Actually there would be a very simple and sane rule for whitespace handling (always return whitespace unless a element contains only elements and does not have xml:space="preserved" set), but the specs require the XML processor to return even the useless whitespace. The XML specification should set up rules that specify how to handle namespace'd elements and attributes that are not supported by the application. Right now the schema defines how to handle them and the application will not get any support by the XML processor. Ideally the application should tell the XML parser which namespaces it supports, and the XML specification should define what the XML parser does with the rest. xml:lang is pretty useless without more rules for the XML processor. It would make sense if the XML parser could somehow only deliver text in the desired language to the application, but without any useful function it just bloats the specification. XML Namespaces are probably the greatest invention in XML history, but they should be in the core specification. Otherwise the APIs are splitted into namespace-aware functions and those that ignore them. The main problem is that the ':' character has no special meaning in the core specification, so you can have well-formed XML with undefined prefixes, several colons in a single name and so on... XML Schema should be deprecated in favour of RelaxNG. I haven't seen a single person who would claim that XML Schema is better. People just use it because of the W3C label.