KDE Blogs 

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. Read More

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.

This is the time of the year where we see our families and get/give gifts. And every now and then we get a gift that piss us off, but to not offend the giver we said we're pleased and take a mental note to get him something as "usefull" as the gift, we just received. And in the following weeks, we keep forgetting that we want to return that thing ... so we wake up in June, still stuck with that ... and even the cat doesn't want to pee on it (it's scaring him/her to death). So you promess yourself to spend xmas in the south the next time ... but you keep forgetting to get tickets, renew your passport etc ... so you're stuck again to get an ugly gift from him/her ... but maybe you can give him back the gift he offered you 10 years ago ;-P Read More

Since I wrote the last entry about properties, the comments and Groovy changed my mind about the property syntax: I think the accessor method syntax that panzi proposed is much better than my Java-like syntax or the C# syntax. If the language uses the 'virtual' keyword for virtual methods, virtual properties (properties without associated member field) can not use 'virtual' as a keyword. Otherwise it would not be possible to override the accessors in a sub-class. But the keyword is not needed anyway, because the new accessor syntax can unambigously define a property. You just need to write one or both accessor methods. For the API documentation only one accessor method must be documented, and it should be documented like a field (and not like a function) Groovy has the simple and effective idea that all public field members are properties. This removes the need for the 'property' keyword and also the difference between properties and fields. Just add a regular member, and it is accessed using auto-generated accessor methods, that can be overwritten by you There's one drawback when properties are accessed like field-members: you can't control anymore whether you access the field directly, or using the accessor methods. This can only be avoided with a syntax extension, and I think the least painful is the following: a method can access the raw field member of the object class without the accessor methods by prefixng the name with a '@'. It is not allowed to use this kind of access for other instances or classes (thus only '@field' is allowed, but never 'ref.@field'). In order to prevent errors, the accessors must not call themselves and thus the attempt to read the field without '@' would cause a compilation error. Here is the example class with these changes: class SubString { private int mEndIndex; /// Documentation! public int beginIndex; /// Documentation! public int length.get() const { return mEndIndex - @beginIndex; } public void length.set(int value) { mEndIndex = value + @beginIndex; } }; It's short. I am not very happy about the '@' thing though. Read More