KDE Blogs 

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.

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.

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

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