Welcome to KC KDE! As you probably know the release of KDE 3.0 turned out well, so did the recently announced KDE 3.0.1. With a very stable 3.0 version at hand, it is obvious that the improvement of KDE features will continue, you can find the first draft of the release schedule leading to KDE 3.1 here. It appears that the first beta version will hit the servers in less than one month. The final version will be probably around in late September.
KC KDE is getting a bit more i18n as Simon Huerlimann volenteered to translate articles into German, expect it to be available real soon.
We hope you enjoy this week's summaries!
While working on a font thumbnail generator, Craig Drummond asked:
As the ioslave is started when a file of a particualr mimetype is selected, I had a look at the mimetypes for font files in mimelnk/applications. In here there are two .desktop files:
x-truetype-font -> for TrueType fonts
x-font -> lists Type1, and *some* bitmap formats.
What I'd like to do is remove the x-font one and replace with the following:
x-bitmap-font -> *.pcf, *.pcf.gz, *.pcf.Z, *.bdf, *.bdf.gz, *.bdf. Z,
*.snf, *.snf.gz, and *.snf.Z
x-ghostscript-font -> *.gsf
x-type1-font -> *.pfa, *.pfb
x-speedo-font -> *.spd
Does this sound reasonable? [...] Would these changes break any existing apps?
Marc Mutz replied,
Mime types are not an invention of KDE, you know. See www.iana.org for a
list of registered mime types. I can find at least on app subtype
registered there. For others, search with google.
Gioele Barabucci pointed out that there weren't any appropriate font mimetypes
registered with IANA, which prompted the following response from Marc:
The problem is that there are too many x- mime types out there. And KMail queries the installed .desktop files and uses the mime type found there, so x-* mime types will get out of the scope of KDE-internal. That's one of the reasons why I fight against them to the point of offering every KDE app assistance in getting mime types registered in the vnd tree for their app (see KOffice mime type discussion a while back).
This is just one step higher.
OSS is not condemned to implement standards the "industry" prescribes us. KDE is powerful enough to set a few standards by itself. And if it's only properly registering new mime types with IANA or trying to get a new top-level mime type "font" on the way...
Sometimes development doesn't go as smoothly as one would hope and the code
ends up in a poor state. Fortunately there is revision control to help back out
changes. Raffaele Sandrini ran into such a situation and asked,
i messed my source file in kmenuedit... there went something completly
wrong. The file is not usable (i'm talking about treeview.cpp) like that? How
can undo this revision? I mean go back one step?
The suggestions starting rolling in, starting with this one from Michael Haeckel:
You can revert it for example by doing:
cvs rdiff -r1.42 -r1.41 kdebase/kmenuedit/treeview.cpp > patch.diff
patch -p2 < patch.diff
Dirk Mueller was next in line saying,
as you apparently didn't commit, cvs up -C will do it.
WARNING: you're loosing ALL LOCAL CHANGES!
Guillaume Laurent offered:
cvs update -j [current version] -j [last valid version] treeview.cpp
It should update your file to the last valid version. You then have to commit again.
Neil Stevens pointed Raffaele to the kdesdk module:
- get kdesdk
- cvsrevertlast file.cpp
- cvs commit -m "Revert" file.cpp
So not only did Raffaele get his code straightened out again, but several good solutions that can probably be used by everyone at one point or another were offered.
KDE is available in approxametely 50 languages - and the number is still growing as approaches start to translate KDE into even non-human languages as Rob Kaper explains:
now that I am no longer alone on this, I am going through with this and would like to announce a new i18n module: i-klingon.
Probably not something we'd like to include in the release anytime soon (Klingon isn't too popular yet), but I don't think our current structure allows us to develop a complete i18n module outside of CVS, so please set us up! All members of our team already have KDE CVS write access.
I'll be the contact for the i18n team, but you can reach the lot of us on the firstname.lastname@example.org mailinglist.
The KDE Romanized Klingon Translation Team
While it was remarked that it is impossible at this point to make use of Klingon glyphs in KDE, Rob went more into detail about the project:
We're not translating to the glyphs, which are not in Unicode yet. We translate to a representation of Klingon in the roman alphabet.
- this solves the entire "you're not in Unicode" issue for the time being
- most Klingn dictionaries use the romanised
Or in the words of the Klingon Dictionary itself:
"There is a native writing system for Klingon (called pIqaD) which seems to be well suited for the various dialects. This writing system is not yet well understood and is, therefore, not used in this dictionary. Instead, a transcription system based on the English alphabet has been devised."re not translating to the glyphs, which are not in Unicode yet. We translate to a representation of Klingon in the roman alphabet.
While the idea was generally taken as revelation for what the K is an abbrievation for, it is questionable wether it will be included in the kde-18n-cvs module. Thomas Diehl pointed out:
With space and adminstrative requirements for the kde-i18n module getting higher and higher and lots of regular teams (eg from India) waiting for inclusion I'm totally against including any fun projects that do not even aim at regular distribution. Besides: If we start including projects like this we can hardly deny it to others, no matter how obscure or badly maintained they are.
Independently from the inclusion into the cvs-module we finally learn about the meaning of the K.
Continuing his attempt to help get KDE's mimetypes registered with IANA, Marc Mutz wrote in saying:
Now that the ZIP format has arrived in KOffice, we can finally register the KOffice mime types.
Please read the template thouroughly, since I intend to send it to the ietf-types mailing list for a two-week comment period before it goes into the IANA registry.
I have changed the magic numbers from what I found in kdelibs/kio/magic in anticipation that the new mime types will also be used internally (at least you already test for both app/x-kapp and app/vnd.kde.kapp in the source).
His message continued with a generic registration that could be used for the various
KOffice applications. Marc finished off with a question, saying,
Please tell me for which
KOffice apps this template holds and for which it needs modifications.
Marc's message created a flurry of responses, including an answer to his question from
I think it applies to those, they all use the KoDocument methods for loading/saving: karbon, kchart, kformula, kivio, kontour, kpresenter, kspread, kword
What do we do about the apps that are not released yet? kdatabase and kplato will surely use xml+zip, but we could register those apps only when they exist, right?
Krita: will it have xml+zip as a native format, or will it only load/save images (jpeg, png etc.) ? Kugar doesn't appear to have an xml+zip format.
After the discussion had settled, Marc wrote in again with an update:
Following is the expanded list of mime types for these KOffice apps: kword, kspread, kpresenter, kformula, kchart, kivio, kontour, karbon
This public review will be not be very extensive, though, so don't count on others doing it - do it yourself! ;-)
Nicolas Goutte responded with a question concerning the security information included in the proposal:
I am sorry to be picky again!
"ZIP archives, XML files and supported image files"
Do WMF (Windows Meta Files) count as images too? What is the security status of those
A small discussion on security ensued, to which Thomas Zander replied:
svg/eps/wml etc are all embedded in the document (but that is optional to begin with). The document that uses the mime-type is a zip; so basically you can include any executable/shell script virus in there as you want. The statement that it does not introduce extra security concerns it therefor complete.
For the people that are afraid that I am sidestepping the problem with that; on the question of using any scripts or other possible virii like code in the archive we keep and always will have the statement that we believe in seperation of document-data and executable-data. We will never allow something to be executed when it (or its container) is marked as document data.
Finally, Marc wrote in saying
As you've seen, I
just sent the mime type reg's to email@example.com for a two-week review.