Welcome to KC KDE!
We (the people behind KC KDE) welcome you (the people reading KC KDE) in this next (as in following the last) issue. I'm planning (I should emphasize "planning" at this point) to be releasing a new KC every Monday from now on. Together with a few other KDE developers I'll be on LISA next week. If you live near Philadelphia, step by to say hi, see us hacking KDE in real-time, posting the next KC, looking good (but then again I always look good), being weird (no, wait, that's just me) and in general being great guys that we are.
This weeks highlights include new Python Qt IDE, Xrandr support in KDE, security in KMail and others.
To everyone who emailed me since the last issue - thank you.
We hope you that you will enjoy this issue as much as we enjoy you enjoying it!
Python support in KDE is already very good. Thanks to the PyKDE package. But the next months will bring us even greater news on the Python / KDE front.
Detlev Offenbach has given some news on the progress of the third version of Eric. Eric started as a graphical debugger for PyQT / PyKDE. The Python brother of Kdbg and is included in the PyKDE distribution. But the next version of Eric will bring not only a debugger but a full-fledged IDE for Python.
Detlev has integrated in Eric Qscintilla : a source editor with code completion and code folding in Python. You can also browse the QT documentation, use QTDesigner and QTLinguist directly from Eric. There are many more functionalities like a Python class browser.Detlev hopes to release an alpha version of Eric v3 before the end of the year and has posted some screenshots to get the mouths to water.
The availability of an opensource Python IDE for KDE is an important step to ensnare new developers like Jack Neal who posted his first message to the PyKDE list :
I have been playing with Linux for a couple months and I initially walked away from it because I couldn't develop for it [...] I'm a VB/MSSQL programmer by trade and I've spent all my life with BASIC - at work we are an all Microsoft shop, so my options are limited there.However, after looking at Qt and Python and seeing that the people on this list tied things together, I am now in the process of ditching Windows and looking forward to doing some work with PyQT and PyKDE in my spare time.
Hamish Rodda announced on kde-core-devel:
X Resize and Rotate is an extension to X which allows resizing, rotating, reflecting, and changing the refresh rate of each screen of an X display on the fly. The extension has recently been committed to XFree86; the next version, 4.3 is planned for release this year.
I've committed a user interface for this extension to kdenonbeta/kcmrandr. It consists (currently) of a control panel and a system tray app. Screenshots can be found here: http://yoyo.its.monash.edu.au/~meddie/patches/screenshots/
Hamish also pointed out some problems with the current implementation. Tim Jansen and Lubos Lunak joined the discussion to help Hamish come with a solution that would satisfy everyone.
All in all, KDE 3.2 will come out with full Xrandr support.
After reading an article on LinuxGuru.net Roger Larsson came on kde-devel asking:
Have you read
http://articles.linuxguru.net/view/198
What to do about it?
One of KMail developers; Karl-Heinz Zimmer was the first to respond saying:
believe me, this is a Hoax! :-D
Please see yourself - I am sure after reading it all you will agree to me:
They wrote:
(...) Finally, the most important 'bug' most distributions have, is allowing a Windows executable to be run with wine without an obvious chance for interception, by default. Sure, it comes up with a window, telling you that wine is running, and allowing you to disable the notice, however, it does NOT warn you about the application being executed in such a way that you could stop it before it was started. (...)
To end the confusion that was caused by this article we would like to state a very simple fact:
This has always been, is and will ever be *wrong*!
The contrary is true: An explicit warning dialog is shown and the user must click on [Open] there - which is *not* the default button.
The dialog e.g. looks like this:
"Open attachment 'notepad.exe' with 'WINE'?
Note that opening an attachment may compromise your system's security!"
So there is no automatic execution of the windows binary, and the user *is* told what would happen if she clicks the [Open] button.
(...)
So it is clear that the statements made in this linuxguru.net article are absolutely wrong.
IMHO this is a Hoax published shortly before the release of KDE 3.1 - perhaps in order to apply some FUD technics to potential KDE users.
Zac Jensen, author of the LinuxGuru article in which he accuses KMail of such grave security hole was somewhat ignorant of Karl-Heinz comments saying:
You really need to chill man, that really wasn't the point of the article. Maybe you're not familiar with American English writing, but, this is *not* a technical article, and if you'd noticed the topic of the article itself, it has nothing to do with kmail, it could've been any application. Like I said in my comments, and I've added since you complained, it's not about KDE or KMail. And the point is only proven further, that, if people can misread this article, they can accidentally press enter on the verification screen in kmail. Maybe, if you are concerned, you should make it so no buttons can be pressed with just 'Enter', if it's not that way already, I stopped using KDE a while back because my computer is too slow and KDE, while nice, is just too massive for my poor old AMD k6-2
Zac also submitted his story to linuxsecurity.com, where it was posted by Eric Lubow. Fortunately, Eric was a lot more responsive, immediately correcting his article after Karl-Heinz intervention.
After private email exchange with a LinuxGuru.net editor Karl-Heinz wrote:
The editor now sent a private mail to me telling me again his excuse about this mistake having taken place (after he already stated this in a long comment below the article to let everybody see it) and he agrees to us covering KDE especially: It is not necessary to write this long and complicated article about "Linux vulnerability" - he just wants us to be sure that the LinuxGuru site _does_ appreciate KDE very much and they are sorry for not having made sure whether the facts published in that false article were true.
So everything ended well.
Marc Mutz emailed KMail mailing list saying:
I've hacked together a short howto that describes how to use OpenPGP/MIME with KMail 1.5. It's intended to be put on the KMail homepage.
Daniel Naber put Marc's tutorial on KMail homepage. You can read it here.
Ingo Klocker responded saying:
As KDE is Qt-based we should recommend pinentry-qt and not pinentry-gtk. I'm using *-qt without problems since a couple of weeks. OTOH with pinentry-gtk not prompt was show because pinentry-gtk seems to have serious problems with non-ASCII characters (like the umlaut in my name). pinentry-qt also doesn't show any non-ASCII characters but at least it shows the other characters.
People shouldn't use Beta2 with the plugin. I installed the Beta2 RPMs at work and PGP/MIME with Beta2 simply sucks (no encrypt to self, super uncomfortable key selection dialog, a load of stupid questions, ...). If users try this they will get a completely wrong impression of the PGP/MIME support in KMail.
Michael Goffioul announced on kde-devel:
A few weeks ago I started to work on a CUPS log file tool/analyzer. This eventually evolved into a modular and versatile generic log file tool with a plugin mechanism (where CUPS is just a plugin now). You can view some screenshots at
http://www.geocities.com/kdeprint/klogtool.html
It's available in kdenonbeta. I won't describe all features here, but the main one is its modularity: support for new log files can be easily added (it currently supports CUPS, Samba and Syslog). The main question (beside would you enjoy it) is which log file would it be mandatory to support? (I'm not really a sysadmin)
Many people submitted a their picks for log files which should have been handled by KLogTool. Andy Fawcett asked for Apache log files and a after giving a website summarizing Apache log file format Michael wrote:
After looking at the doc, it seems pretty feasible to add apache support for error_log and access_log format. For the latter I would however put 2 restrictions:
- each log entry is a single line
- fields with spaces are quoted (otherwise it seems impossible to parse)
So if you need a log analyzing tool try KLogTool and give Michael your feedback.
On Saturday Ariya Hidayat wrote to koffice-devel saying:
It's been roughly six weeks after KOffice 1.2 release time, but of course "The road goes ever on and on". Here I'd like to summarize some new KOffice filters which have been developed so far:
- MagicPoint import filter for KPresenter (Lukas)
- OpenOffice.org Calc import filter for KSpread (Norbert)
- OpenOffice.org Writer import filter for KWord (Laurent)
- StarOffice Writer 5.x import filter for KWord (Marco+Ariya)
- SVG import filter for Karbon (Rob)
..and others which (hopefully) come alive soon: StarOffice Calc 5.x import filter for KSpread (Norbert) OpenOffice.org Impress import filter for KPresenter (Laurent)
Also, don't miss improvements on other filters, like with Microsoft Word import (Werner+David), Gnumeric import (Norbert), Excel import (Ariya), RTF import (Nicolas), and many more. If I miss something, then please speak-up.
Now KOffice starts to be able to handle most popular document formats out here. "One office suite to rule them all..."
Lenny Kudling added:
I'd like to add that karbon has a nearly (80% ready but not usable yet) Gimp Export Filter. Anyone looking for a small, high prestige project without the need of nearly any koffice knowledge?
Robert Jacolin joined the discussion saying:
Well, it's a good opportunity to say I'm working on a new kspread latex export filter. Nothing on cvs, right now.
Robert went on explaining what he's working on. Things that you can expect from him include:
KOffice is certainly shaping up to be the office suite of choice for all of us. Make sure you visit koffice-devel if you wish to help.
Mosfet is back. He basically rewrote and released new Liquid style. Mosfet also emailed kde-core-devel asking about transparent panel for which I'm responsible. Transparent panel won't be in KDE 3.1 because I didn't make it in time before the feature freeze, sorry. Hopefully because of the longer testing/development period together with Mosfet we will come up with something truly unique.
On the eye-candy front kde-look.org people are coming up daily with different Kicker Menu mockups. We (the developers) haven't taken a stand on which one is the best, or which one is going to be implemented. The final decision belongs to our usability group, but we do read kde-look.org so make sure you vote for the design that you like the best.