KDE Commit-Digest for 21st October 2007

In this week's KDE Commit-Digest: Fortune-teller and Keyboard Layout applets for Plasma, KNewsTicker resurrected for KDE 4.0 as a Plasmoid. Rewrite of <canvas> tag support in KHTML. Various new language syntax highlighting in Kate. Internal database storage work in Digikam. More playlist handling work, and support for Magnatune "streaming membership" in Amarok 2. OpenDocument loading of charts in KChart for KOffice 2. Various graphics fixes and a user handbook for the Bovo game. Kolourpaint is now fully ported to Qt4. Continued work on the Eigen 2 library. Further porting away from KDEPrint to the printing facilities provided by Qt4.

Dot Categories: 

Comments

by Darryl Wheatley (not verified)

Thanks very much for the update Aaron! I enjoy your blog posts and your youtube videos. Just like everyone else, I'm really impressed with the progress - KDE4 may well become the gold standard against which all other desktop ecosystems are compared. For me at least anyway :)

by James Richard Tyrer (not verified)

IIUC, this KCM is now a Plasma applet.

Is this going to work with Xorg-7.3

Note that it does not install a file:

/X11/xkb/rules/xorg

by fprog (not verified)

Can someone includes this in KDELibs4 ?

http://kde-apps.org/content/show.php/QStringTemp+for+KDE+3.x+%28CVS%29?c...

It basically, allows you to write this:

QString s("is");
KStringBuffer buffer;
QString result = buffer + "Th" + s + ' ' + s + " way " + 't' + "oo cool";

Instead of writing this, due to the Proxy String Design Pattern:

result += "Th";
result += s;
result += ' ';
result += s;
result += " way ";
result += 't';
result += "oo cool";

If you LHS object is a QStringBuffer, then the compiler will know,
that you are concatening a "set of" strings instead of creating many temporary QString.

#include "qstring.h"
class Q_EXPORT KStringBuffer : public QString {
public:
Q_EXPORT inline KStringBuffer() : QString() {
QString::reserve( 128 );
}

Q_EXPORT inline KStringBuffer(register size_t sz) : QString() {
QString::reserve( sz + 64 );
}

Q_EXPORT inline KStringBuffer& operator+( const QString &s2 ) {
QString::operator+=( s2 );
return *this;
}

Q_EXPORT inline KStringBuffer& operator+( const QLatin1String &s2 ) {
QString::operator+=( s2 );
return *this;
}

Q_EXPORT inline KStringBuffer& operator+( const QByteArray &s2 ) {
QString::operator+=( s2 );
return *this;
}

Q_EXPORT inline KStringBuffer& operator+( const char *s2 ) {
QString::operator+=( s2 );
return *this;
}

Q_EXPORT inline KStringBuffer& operator+( QChar c2 ) {
QString::operator+=( c2 );
return *this;
}

Q_EXPORT inline KStringBuffer& operator+( char c2 ) {
QString::operator+=( c2 );
return *this;
}
};

by Kevin Krammer (not verified)

This is certainly not the right place to post a wish like this.

kde-devel or kde-core-devel are surely more appropriate to suggest such an addition for KDE 4.1, but remember to have at least the names of two applications which use it.

What exactly is the difference between using QString directly?
I.e. why not

QString s("is");
QString result = "Th" + s + ' ' + s + " way " + 't' + "oo cool";

by fprog (not verified)

You just constructed and allocated memory for 6 temporary QString instead of appending them to result, one for each dummy operator+(lhs,rhs).

While this creates one large enough KStringBuffer and appends to it, WITHOUT creating temporary QString, the reason is that the buffer prefix changes the way the concatenation work by appending to itself, instead of creating temporary QString that will be allocated and freed successively.

Another way of doing it properly would have been to return this type of subclass directly from the QString::operator+() construct, but this breaks QT4 which is undesirable, so this work-around is required instead, which also works without modifying the core QString class.

For small strings the gain is negligeable, but if you concatenate big statements like a 16 lines SQL query or similar then the gain is non-negligeable. It also makes the code way more readable than using .append() or operator+=() all over the SQL parts.

KStringBuffer buffer;
QString result = buffer + "Th" + s + ' ' + s + " way " + 't' + "oo cool";

by Kevin Krammer (not verified)

Well, if it is a good way to improve performance, it probably won't be a problem to find some developers who want to use it.

You'll need a suitable licenced and documented file and advertise it to application developers.

Once the rule for at least two application's using it is met, anyone can suggest it for inclusion in the KDE 4.1 kdelibs