Kernel Traffic
Latest�|�Archives�|�People�|�Topics
Wine
Latest�|�Archives�|�People�|�Topics
GNUe
Latest�|�Archives�|�People�|�Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

KDE Traffic #21 For 24�Aug�2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! This week's installment celebrates the fantastic pace of the work being done on KDE3. The move to Qt3 is an important transition for KDE, despite the temporary pain it may bring. The next several months will see breakages in compiling and in functionality that are inevitable during such a wide-scale porting effort. Binary compatibility breakages will be committed to CVS each Friday, potentially requiring a rebuild of much if not all of the KDE source tree. It also means that those wishing to develop or test the bleeding edge will need to install the latest Qt3 beta (or use the copy in the qt-copy KDE CVS module). While it is possible to keep a copy of both a stable release and a development version of KDE on the same machine (which many KDE developers already do), the challenges presented are not small ones for many would-be participants.

To make KDE3 as good as it can be, developers and testers are required. So, why should one decide to take the plunge and live in the potentially chaotic world of KDE3 development that will exist for the next few months? Besides helping KDE to become the greatest desktop environment available, those around during this time will be able to see and use all of the new and improved capabilities in KDE3 months before the rest of the world gets to enjoy it. This issue of KC KDE highlights several of the developments that have occurred over just the past 2 weeks in KDE's head CVS branch. It is by no means a complete study of every current development nor does it cover those features that are still in the planning stages, but hopefully this issue can provide an exciting insight into the development of KDE3.

We hope you enjoy this issue and (as always) Happy Hacking!

1. Touch Typing and Other Educational Apps

7�Aug�2001�-�11�Aug�2001 (6 posts) Archive Link: "Moving KTouch"

Topics: KDE-Edu, New Application

People: Haavard Froeiland,�Waldo Bastian

Where do you go when you want a selection of educationally oriented applications for KDE? Perhaps apps.kde.com, or freshmeat.net. Many are probably not aware of the relatively new kdeedu package that is housed in KDE's CVS repository. kdeedu is a relatively small small package housing only three applications, the most recent addition to which is KTouch.

KTouch developer Haavard Froeiland said, " KTouch is a small education application for learning to touch type. I would like to move it from kdenonbeta to one of the packages being released. It would be nice to have it in kde, since there is many people out there who want to learn to touch type, and especially for schools installing kde. http://ktouch.sourceforge.net/"

Waldo Bastian replied saying, " Seems like an excelent candidate for the recently created module "kdeedu". There is also a special mailinglist for educational issues in the form of kde-edu@kde.org."

Hopefully more educational applications will be imported over time into kdeedu to make it as rich a resource for KDE users as the other packages are.

2. Cookbook and kdeapps?

8�Aug�2001�-�9�Aug�2001 (7 posts) Archive Link: "kde-apps (or whatever) and Cookbook"

Topics: New Application

People: David Watson,�George Staikos,�Stephan Kulow

Here is the scenario: a developer has been working slavishly on their new KDE application masterpiece. Needing a place to house it during development, they have put it in the kdenonbeta module. The time eventually arrives for it to graduate from the land of half-finished programs into a proper place in CVS. If the program in question fits neatly into one of the existing modules, this isn't a problem. But what of the numerous applications that don't really fit well into the any of the core categories? One such application is David Watson's Cookbook, a promising KDE recipe application. After some discussion as to what to do with Cookbook, David wrote, " There has been quite a bit of discussion as to what will be done with my poor little unwanted program ;), and it sounds like most people are in favor of the creation of a new kde-apps (or kde-misc, or kde-foobarbaz) - so is this actually going to happen? It would be nice if I weren't just left hanging like this - the suspense is killing me. :) Not really in such a hurry, just want to know what's going to happen..."

George Staikos unwittingly summed up the situation, saying, " It seems like there can be no strong correlation between these applications that would be in the new package. Why not just package these things separately? I don't want to have to install KVirtualBarbieCollector in order to get KCookBook. I see a difference between a collection of small screen toys (kdetoys) and full apps. I'm not saying that I don't want to see KCookBook or other apps distributed with KDE though. I'm actually quite curious about KCookBook. I'm just saying that it might be better to allow fine-grained installation of these apps. As an alternative, they could, I guess, be put into a single module and then hopefully have the packagers make separate packages for each app inside." Stephan Kulow replied, " That's actually _exactly_ what kde-apps is supposed to be - just a place different to kdenonbeta for apps to be in CVS."

To date such a cvs module has yet to be added though it seems likely to occur as more and more applications are being built within KDE's CVS.

3. Support For Large Files

10�Aug�2001�-�11�Aug�2001 (13 posts) Archive Link: "Fwd: Re: 64 bit file support"

Topics: Operating Systems

People: Waldo Bastian

As 64-bit operating systems become more common, support for large files becomes important for the desktops that run on them. Lack of support for large files is a known limitation in KDE2 which will be addressed in KDE3, as Waldo Bastian said in an email to the kde-core-devel list, " One of the things todo for KDE 3.0 is to get 64-bit file support working. You might want to read the following URL in order to understand the problem. http://ftp.sas.com/standards/large.file/x_open.20Mar96.html It seems that since we can't control the way in which either Qt, other libs or applications are being compiled we will need to use the "Transitional Extensions". I haven't tried it yet but I hope that we can circumvent this define mess that Jeff talks about. I'm sure that after all the problems with X-headers the glibc-developers wouldn't be that stupid. As far as KDE's internal interfaces goes, I think that we should start to use "long long" in the interfaces that need it. Maybe we can add a KIO::filesize_t typedef so that we have a central place to change it to something else."

Waldo later replied to himself saying, " The solution to this seems to be to define _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE and to leave _FILE_OFFSET_BITS undefined. You should then be able to use stat64() and other 64-bit versions of the stdio functions. The normal functions remain 32-bit then. That also means that you have to use "struct stat64" instead of "struct stat"." Then in reply to that message, Waldo posted a patch that provided a starting for large file suppor.

4. Kompare Moves Into Main CVS

11�Aug�2001�-�16�Aug�2001 (6 posts) Archive Link: "Moving and renaming kdiff"

Topics: CVS

People: John Firebaugh

KDiff has been moving steadily towards completions during its incubation in kdenonbeta. The moment finally arrived to move it into one of the main CVS modules this week as John Firebaugh announced:

I'd like to move kdiff from kdenonbeta to kdeutils and rename it to kompare at the same time. Thanks to Dre for the name suggestion. Unless there are any objections, could someone with access please make the move on the server?

It was recommended that it be moved to the kdesdk module instead, which is where it is slated to be moved.

5. The Evolution of KNode and KMail

10�Aug�2001�-�14�Aug�2001 (20 posts) Archive Link: "[RFC] Kmail to use Knode message classes and proposed schedule for"

Topics: KMail, Code Reuse

People: Marc Mutz,�Don Sanders

KNode and KMail have many cosmetic and functional similarities since they both handle text based messaging. Each of them has a message composer, message threading, support for attachments, encryption capabilities, hierarchical views, etc. Many have wondered just how many of these common components (and therefore development effort) could be shared between the two projects. As it turns out the answer is, "quite a lot". KDE3 will see a merging of many of the capabilities and components of the two applications, as Marc Mutz outlined in an email cross posted to both the KMail and KNode development lists, saying:

The Knode developers and Marc Mutz (from Kmail) have come to an agreement on how to merge the message handling of the two projects. This will be the first step on the road at whose end Kmail and Knode are only frontends to a common library and the creation of a "KMessenger" superset of both to rival Outlook will be possible. We think that there is a consensus on both sides that this is the way to go.

We now want to lay out the schedule for this first part (with time frames intentionally left out of the picture):

  1. Outsource KNode classes into libkdenetwork (splitting up KNArticle into a Knode-specific and a generic part).
  2. Rename classes under a KMime:: namespace and port to Qt3.
  3. Optimize the classes for both memory usage and RFC compliance.
  4. Rewrite KMMessage / KNArticle as wrappers around KMime::Message (defining a common load/store interface for on-demand loading of message parts - some KMime::LoadHelper or such).
  5. Create a transparent encryption/decryption (multipart/{encrypted,signed}) interface for bodyparts based on Ian's work on KGpgMe (codename:-) and George's S/MIME classes.
[now ready for release]
  1. Move Knode/Kmail semantics over to KMime and consolidate.
  2. Merge reader classes (actually, rewrite them to become a KPart and maybe use QTextBrowser for mails that don't contain HTML themselves (should be much faster)).
  3. Merge Composers and make them use QTextEdit, so that we can create text/html (ugh. :-) and text/enriched mails.
[in the future:]
  1. Merge the message list classes.
  2. Merge the rest (esp. folder handling).

Though this proposal seems like "Knode takes over Kmail" (or---as Christian Thurner has put it: "We are KNode of Borg. You will be assimilated. Resistance is futile" :-), this is not so. We use the MIME framework of Knode as a basis, because it's technically sound and Kmail's isn't, but the outcome of the merge will look quite different from current Knode. What with the reader and composer; they will need quite a bit of work for the port to QTextEdit and it's not decided in any way from which side (Kmail/Knode) we start there.

Regarding the message class sharing Don Sanders replied, " initially the API of KMMessage shouldn't change, only the implementation. This way the new KMMessage can be tested for correctness. Then the KMMessage API should be extended with load on-demand of message parts and I think more importantly methods for treating the entire message, message body and each message part as a stream. Then KMail can be ported over to using these streaming methods and finally KMMessage::asString and the like can be removed completely. Treating message parts as streams should allow large messages to be handled efficiently memory wise (speed is not so important)." Marc agreed that this is exactly how it should be done.

The discussion progressed to cover advanced encryption handling, gpg integration, cooperation with PIM applications and kparts usage. KNode and KMail will probably both come out of this looking and feeling different than they did in KDE2 to the general improvement of both applications.

6. EMail Templates in KMail

12�Aug�2001�-�17�Aug�2001 (7 posts) Archive Link: "Patch: templates for kmail (Bug #1015)"

Topics: KMail

People: Florian Weber,�Ingo Kl�cker

Word processors, spread sheets, presentation packages and HTML editors all come with support for template documents, so why not do the same for EMail programs? Florian Weber posted such a patch for KMail saying, " Well, my guests left early, so here is the first (incomplete) draft for mail templates." Florian went on to list what the patch already accomplished and what was left to do.

Ingo Kl�cker questioned the wisdom of letting any mail folder become a template folder, as Florian's patch allowed. Florian explained his thoughts on the matter saying, " I was thinking about those people who would like to have multiple template folders. In my experience, users often like to sort their mails/templates/whatever by projects. This is made impossible by a single, system-wide template folder. I agree that most home users will (probably) use a single template folder. In an enterprise environment however, splitting things up can be an absolute neccessity."

7. KWinTV Sees Active Development

14�Aug�2001�-�20�Aug�2001 (15 posts) Archive Link: "KWinTV"

Topics: Multimedia

People: George Staikos

What do you do when you discover that a certain program you rely on isn't being maintained anymore? If you are George Staikos you take it as a call to arms and correct the situation. With a desire to see KWinTV working properly, George posted to the main devel list saying,

This is a note to inform you that I have received no feedback from the KWinTV author and he doesn't seem to have done any work on it since November, so I am starting to maintain it myself in KDE CVS. It's in rather rough shape right now, but it does work and I have fixed many bugs already. I have also applied a patch by Stefan Hellwig which makes the channel scanner work and implements a brand new channel file format.

Things are stable enough for me right now, but I can find ways to crash it still, and some things just aren't being done in a nice way. Ideally it could use a complete rewrite since it was originally based on KDE 1.x but I just don't have time for that. So for now, I'm just going to plug away at my TODO list which I have added to the app in CVS. You can find it under kdenonbeta/kwintv. This is not in the main build because it doesn't use the KDE build system yet. I'm not a pro at that, so it will take a while to merge it. For now I will continue to make releases fairly frequently at http://www.staikos.on.ca/~staikos/kwintv/.

George also put out a call to others who use the application to send in patches, fixes for the build scripts, icons, documentation, etc. Almost immediately KWinTV was put into shape with an inspiring number of commits to CVS over the next several days. The users of KWinTV are no doubt happy that this program is once again moving in the right direction.

8. Advanced Web Shortcuts Now In CVS

15�Aug�2001�-�16�Aug�2001 (4 posts) Archive Link: "Can I put my advanced web shortcuts into CVS?"

Topics: Konqueror

People: Andreas Hochsteger

Andreas Hochsteger's development efforts on extending Konqueror's web shortcuts to support multiple search terms and flexible insertion patterns occurred during the KDE2.2 feature freeze and therefore did not make it into that release. With that freeze lifted Andreas asked, " I just got my own CVS write account from Stephan, so are there any objections, which will prevent me from commiting my changes into the HEAD branch? FYI: I've posted several patches, some time ago and the functionality has been extended and matured much since that time." Andreas was given the green light and his patch was committed to CVS for testing and exploration.

9. New KDE Website: enterprise.kde.org

21�Aug�2001 (7 posts) Archive Link: "enterprise.kde.org"

Topics: New Website, KDE in the Enterprise

People: Jonathan Bacon

Jonathan "Jono" Bacon has been busy with the KDE usability project, but that hasn't stopped him from taking on other projects as well. Jonathan announced the availability of a new KDE website saying,

I just thought I would let you know that enterprise.kde.org has gone live today. :-)

I am going to be concentrating on pushing KDE as a solid platform for application development and system integration for the enterprise.

The site went live today with it's basic functionality, and a few bugs ;-P, but I will be aiming for the following features:

There is also a mailing list - kde-enterprise. All are welcome to join. :-)

As a further insight into his plans for enterprise.kde.org, Jonathan said:

I am going to be starting work this week on the following on the site:

If you could ask all those people who use KDE at work to get in touch with me that would be great, and anyone who has made a presentation with slides on KDE and the enterprise is welcome to put their slides on the site.

10. S/MIME Support for KDE3

21�Aug�2001 (6 posts) Archive Link: "S/MIME for KDE 3.0"

Topics: KMail, KDE 3

People: J�rg Beermann,�George Staikos,�Marc Mutz

The mail facilities in KDE may not have all the visual frills one might find elsewhere, but it is hard not to respect the ever increasing range of capabilities provided. With each release KMail has become more flexible and capable without losing its stability or clean interface. All is not done, however. One ability that is being asked for frequently these days is S/MIME support. A new face appeared in the KMail landscape when J�rg Beermann wrote, " I'm realy intressted in PKIX stuff and want to join the development of such an S/MIME class for KDE. So let me know if I'm welcome :)" George Staikos replied, "You certainly are. As you know, I've been doing the certificate code, and I have the template here to write the OpenSSL backend support. What I most need help with is defining the interface needed in KMail, and implementing the code in KMail once the KSSL stuff is usable." J�rg's reply to this was: "helping to define the Interface for KMail seems to be a nice task. By the way, I'm a little bit experienced in S/MIME and x.509v3 stuff so maybe I could be a good help for you. I have worked with OpenSSL as well to implement an S/MIME solution, the Library is realy great, but without documentation its a realy ugly job"

Technical discussion on the implementation details ensued between J�rg, George and Marc Mutz. Work on the KMime library has begun and significant functionality has already been achieved.

11. Plugins For the KMenu

22�Aug�2001�-�23�Aug�2001 (1 post) Archive Link: "Kicker extension"

Topics: Kicker, Printing

People: Michael Goffioul,�Joseph Winninger,�Joseph Wenninger

First, Michael Goffioul wanted a good printing system in KDE so he wrote KPrint. Once that was done he needed a way to configure those printers so he wrote a KControl module and a services extension for Konqueror. Then he wanted printers to show up dynamically in the KMenu. To accomplish this Michael implemented a means to dynamically extend the KMenu at runtime. Describing the latest place his quest for printing nirvana has led him, Michael said:

Following an idea I had, I implemented an dynamic extension mechanism to kicker. Basically, this mechanism allows to add menu entries to the K-menu using dynamically loaded libraries (kind of plugins). I applied it to the integration of kdeprint into kicker and you can see the result here: http://users.swing.be/kdeprint/kicker_ext.png (note: when you select a printer, the job viewer is started with that printer).

Technically:

This allows to build tools like "quickbrowser" except that it is dynamically loaded.

Joseph Wenninger responded saying, " it sounds like something I would have needed some time ago, but hadn't the time to implement it. Why does it need to be in kdeui ? It is only usefull for kicker, isn't it ?" Michael agreed and refactored the code to make it cleaner and put it into the kicker library. He posted his final results saying:

I completed the previous code to be able to add this dynamic menu also as a button into the panel (with a popup menu). Now it's working OK. You can see all the results here:

12. Breaking Binary Compatibility on Fridays

22�Aug�2001 (1 post) Archive Link: "reminder: CVS HEAD / BIC day"

Topics: KDE Core Development, KDE 3, Building KDE

People: Dirk Mueller

Binary incompatible changes to libraries, which require the apps that use those components to be recompiled, can be frustrating and take up valuable time. However, With some coordination the annoyance can be kept to a minimum. To that end KDE3's release maintainer Dirk Mueller announced:

due to popular request I'd like to ask everyone to schedule binary incompatible changes in kdelibs to one day per week, that is Fridays.

If somebody has no time to commit binary incompatible changes on such a friday for whatever reason then please mail the patch with a commit log to me and I'll commit it for you.

13. KRegExpEditor: Graphical Regular Expressions

23�Aug�2001 (1 post) Archive Link: "Announcement: KRegExpEditor now available in kdelibs/kdesupport"

Topics: KDE Core Development

People: Jesper K. Pedersen

A year and a half of hacking by Jesper K. Pedersen has resulted in the KRegExpEditor, which is now part of the kdeutils package. Jesper explained what KRegExpEditor was, saying:

The last 1 1/2 year I've been working on a graphical editor for regular expression. Finally I got it complete enough so that it is useful in applications.

What is KRegExpEditor

=====================

KRegExpEditor is basicly just a widget. A large one however. The widgets resemble quite a lot a drawing tool.

From a programmers point of view this is just an alternative to a QLineEdit for asking the user for a regular expression. From, a users point of view, however, this is an good chance to use regular expressions without having to learn some hard-to-remember ascii syntax.

Try a demo

==========

In kdeutils/regexptest there is a very small program that shows the widget in action. To give you an expression of how easy it is to use this widget, here is the program in its whole length:

 #include <kregexpeditor.h>
 #include <kapp.h>
 #include <kcmdlineargs.h>

 int main( int argc, char* argv[] )
 {
 KCmdLineArgs::init(argc, argv, "RegExp Example","","");
 KApplication myapp( argc, argv );

 KRegExpEditor *regexp = KRegExpEditor::createEditor(0);

 regexp->show();
 myapp.setMainWidget(regexp);

 return myapp.exec();
 }

For this program to work, you need to cvs update and compile kdelibs/interfaces, kdeutils/kregexpeditor and of course kdeutils/regexptest

See some screen dumps.

======================

You can see some screen dumps of the test program at work at http://www.blackie.dk/KDE/KRegExpEditor.

All the icons have not been drawn yet, so please bare over with my own drawing ;-)

What is required for it to work

===============================

To use the widget you must link your application with -lkregexpeditor. If you have kdeutil installed then you will get this fancy graphical editor. If not, then you will get a null pointer back from the call to KRegExpEditor::createEditor, and it is then your responsibility to just offer a lineedit to the user.

The idea behind this is that the widget is quite huge (takes several minute on my dual PIII-800 to compile). Therefore it needed to be placed somewhere else than kdelibs/kdebase still several programs in kdebase might use it if available.

As a result an interface is located in kdelibs, and the actual implementation is located in kdeutil.

This sort of project takes a lot of determination and time but will undoubtedly be useful to many KDE users.

14. EMail List for KDE3 Users

23�Aug�2001 (1 post) Archive Link: "New List! kde3alpha"

Topics: KDE 3, New EMail List

People: Christopher Molnar

Leading up to KDE2 there was an email list for those who were using the pre-beta releases to compare notes and generally keep up with what was happening. Now that KDE3 is on the way, a similar list has been created. Christopher Molnar detailed the plans for the list saying:

Well, it's been a little over a year since the removal of the kde2-alpha list that allowed users of what has since become kde 2, then 2.1, now 2.2 to communicate, report bugs, and help each other work through problems. It was a hell of a development cycle and that list helped a lot of additional people test and provide input into the final product.

Now along comes the planning stages of KDE3. Already we are seeing some major enhancements to the HEAD branch of CVS. So, here we go again, it is time to create a new list!

I would like to announce the creation of the KDE3ALPHA mailing list and explain it's purpose:

Subscription is at: http://mail.kde.org/mailman/listinfo/kde3alpha or via email at: kde3alpha-request@mail.kde.org

The kde3alpha list is created for the purpose of users (non-developer types) to communicate problems, sollutions, and bugs to each other and then in turn to developers who may be monitoring the list. The list is also being created with the hopes that a lot of the install/compile problems that end up in the bug database can be resolved on the list rather quickly between users.

I would like to request that those people who build nightly or weekly builds of CVS HEAD branch and make them public consider joining this list so that you may answer questions regarding your builds. (You may also want to consider sending a note to the list telling where people can find your builds).

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.