KDE Blogs 

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

So Eugenia's proposal for a new "usable" widget style (what is dotNET, anyway, chopped liver?) was wrapped in an envelope today as a "KDE style challenge", whatever that's supposed to mean, by someone I happened to see on IRC. I then explained that, despite the fact that the snake menus she put on her mockup are nifty looking, they are in fact insanely difficult to code, but not impossible. Just ugly and scary. Read More

I do not know much about Eiffel (and I can't stand its Pascal-like syntax...), but the Eiffel feature that I like is design by contract. Design by contract means that function interfaces, the APIs, are seen as a contract between the creator and the user. In most languages this contract is mostly written down in the documentation. Eiffel has them written in the source code. It is also possible to do this in a language like Java, but Java's syntax needs a small modification to make this really comfortable. Let's take this function as an example: Read More

in prep for 3.2, i've been looking at some of the default settings and fixing up some of the errant ones... like no desktop text shadows, or soft line wrap in kedit... lots of little fiddly stuff.. and working on fixes for editting bookmarks with the context menu (the dialog is a little lackluster) and for ensuring that important servicemenus like the mount options are in the top level and not buried in the Action submenu. Read More

One of my favorite C++ features is resource management with stack-allocated objects. It can hardly get more convenient than writing { QMutexLocker m(myMutex); } to protect a resource from concurrent access. Java even introduced a keyword (synchronized) to get the same effect, but it is only useful for thread synchonization. In C++ you can use the same mechanism for everything, from files to database transactions. Java gives you the choice between creating a try/finally block to deallocate the resource explicitly and keeping the resource until the object is finalized, which may keep the resource allocated for an infinite time. It's a common error that people write something like this Read More

Bruce took his reply to the KDE proposal off his website and replaced it with four short paragraphs that are much more to-the-point and not nearly as dubious as his original piece. The web is vastly impermanent, which can be good but is often unfortunate as we lose our history and context easily. in related news JDub has said written up in his blog (http://www.gnome.org/~jdub/blog/) how dissapointed he is in some of the KDE people for the trail of snipes that occured on the User Linux discuss list in the last few days; i agree with his sentiments but wonder why he felt the need to whine about it in his blog. (hey, how self-referential! look at me, i'm Kevin Smith.) if it wasn't for the fact that we're doing a lot of cool stuff (e.g. code and technical specs) on the kde-debian list, i'd be seriously in the dumps right now. oh well... Read More

Well up until now most KJSEmbed examples we have had seemed very contrived. This morning we got into a problem with building buttons for our web site. We decided it was not worth doing in PHP since the buttons never changed, but none of us had the talent to build them by hand. So enter "cvs:[kdebindings/kjsembed/docs/examples/buttonmaker/buttonmaker.js|ButtonMaker]" :) Read More

Today I realized that the property syntax of in all C-based languages sucks. Lets a assume a very simple class called 'SubString' that describes a fragment of a string and has two properties: its length and the index of the first character of the string. The class implementation has two field members, one containing the first character's index, and the other the index of the first character after the string. One problem is that there is no field member corresponding to the second property. This is what I call a virtual property. In this simple example there is no real reason for having a virtual property, but in reality this happens quite frequently when you want to expose a value of an aggregated object. Let's try to implement this in Qt/C++, Java and C#. Read More

Here are the points in the order they were presented in Bruce Peren's reply to the KDE in User Linux proposal, along with my thoughts on them. It's All Emotional Bruce first tries to explain it away by saying, "it's simply unbearable for their personal GUI not to be the one chosen for our project", after making references to emotional investments. He's right in that people do care for and about that which they create. He's wrong in that the "emotional investment" is why many of us had issues with the choice to ban KDE/Qt from his project. Read More