KDE Traffic #19 For 3 Aug 2001 By Aaron J. Seigo Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Threads Covered 1. 23 Jul 2001 - 26 Jul 2001 (11 KDE Usability Project Back On Its posts) Feet 2. 23 Jul 2001 - 27 Jul 2001 (19 The Road Ahead Includes a New Release posts) Manager 3. 25 Jul 2001 - 26 Jul 2001 (7 New Version of QextMDI posts) 4. 25 Jul 2001 - 26 Jul 2001 (36 Possible Directions For KConfig in posts) KDE 30 5. 26 Jul 2001 - 28 Jul 2001 (5 Konqueror Showing Progress posts) 6. 27 Jul 2001 (24 An Option For The Speed Obsessed posts) 7. 30 Jul 2001 - 31 Jul 2001 (15 Objections to Exceptions posts) Introduction Welcome to KC KDE! This week's issue comes in spite of downed email servers, ISP's giving up the ghost and all sorts of general network troubles that made me start to think that I was living in the middle of some cosmic conspiracy to deny my systems access to the Internet. On a brighter note, KDE 2.2 is ready to go and the road towards KDE 3.0 is already being forged. Binary compatibility in the libraries is set to be broken to allow needed improvements while others are breaking KDE speed barriers. These events and more are covered in this issue. Enjoy and happy hacking! 1. KDE Usability Project Back On Its Feet 23 Jul 2001 - 26 Jul 2001 (11 posts) Archive Link: "Getting the ball rolling" Topics: KDE Usability Project People: Jono Bacon Some months ago Jono Bacon along with a few other KDE hackers started working on a project intended to help guage the usability of KDE. Unfortunately their time became limited and the project stalled for a while. It picked up steam again this week and is once again proceeding with vigor. Jono kicked things off with this email: From some discussion it is clear we need some form of usability testing. This will not only give our product a sheen but also identify areas of user preference in what users want. What I need to know is who can help and what they do? IF anyone can help witht he following it would be great: * Web programming * Usability research * Writing * Developing questionnaires / research suites If you could outline which areas you can help in that would be great. Since that email, there has been more activity on the kde-usability list that there was in the previous four months. Many new faces have joined the project and they are busy putting together standardized formats for reports, questionaires, software to help automate the testing process and report drafts. To see the state of the project and join in visit http://usability.kde.org/. 2. The Road Ahead Includes a New Release Manager 23 Jul 2001 - 27 Jul 2001 (19 posts) Archive Link: "RFC: The Road Ahead" Topics: Release Schedule, KDE 2.2, KDE 3 People: Waldo Bastian, Dirk Mueller To make sure that there were no questions remaining about the future timeline for KDE Waldo Bastian posted the following summary: To wrap up the Qt3 discussion and to bring everyones expectations a bit in line, here is a proposed time-table for the rest of this year: * Aug 2001: Release of KDE 2.2 * Sep 2001: Release of KDE 2.2.1 * Okt 2001: Development release, KDE 2.89 aka Qrash3. * Nov 2001: KDE 3.0beta1 * Dec 2001: KDE 3.0beta2 * Jan 2002: KDE 3.0 final I suggest to switch KDE CVS to Qt3 after the release of 2.2.1. If you would like to be the release dude for KDE 3.0, now is a good time to step forward :-) There was a brief discussion regarding whether to move KDE development into a two phase schedule, much like Debian Linux' stable and development branches. It was decided through discussion that this was not the best thing for KDE. As for the "release dude" position, when Waldo announced that KDE 2.2 was tagged and ready to go he also announced that Dirk Mueller will be the cordinator for the KDE 3.0 release. Waldo's hard work with the 2.x series has been greatly appreciated by all in the KDE community and we look forward to Dirk's release schedule leadership. 3. New Version of QextMDI 25 Jul 2001 - 26 Jul 2001 (7 posts) Archive Link: "QextMDI --> kdelibs ? [was: Re: ANNOUNCE: QextMDI-2.0.0 Beta1 out now]" People: Falk Brettschneider QextMDI is a toolkit that implements a multiple document interface (MDI) API for Qt and KDE. Several Qt and KDE applications use this framework. Falk Brettschneider announced a new beta of QextMDI 2.0 was available on its homepage (http://www.geocities.com/gigafalk/qextmdi.htm) . According to the announcement, the changes in 2.0 include: * lots of new bugfixes, especially concerning focus problems * KDockWidgets of KDE-2.2 integrated, compile on Win32, too * TabPage MDI mode added, (the third MDI mode!) * Toplevel MDI mode works without focus problems * KDE 2 default decoration and KDE 2 laptop decoration added * optimized and speeded up * several new state signals and useful custom events * added faked SDI mode (just maximized view without system buttons) * dockable tool views (using KDockWidgets) * internal rewrite of several mechanisms * KDevelop project file updated to KDevelop-2.0 * example applications improved * autoconf/automake project files updated to latest version * HTML class reference updated with latest KDoc 2.0a53 * configure script added, with -kde2 and -release flag 4. Possible Directions For KConfig in KDE 30 25 Jul 2001 - 26 Jul 2001 (36 posts) Archive Link: "RFC: KConfig changes for 3.0" Topics: KConfig, Development Plans, XML People: Rob Kaper, Simon Hausmann, Charles Samuels, Martijn Klingens There is only one way to know how well a car drives, and that is to actually get in and drive it. Similarly for an API, the only way to really understand its capabilities and limitations is to use it in real world situations. KConfig is one of those ubiquitous parts of the KDE base libraries: any KDE application that needs to store configuration data (which is the majority of them) use it. The strengths and limitations in KConfig have therefore been discovered in detail and the future of KConfig has been discussed several times before. Now that KDE is heading for a new major release in 3.0 it was to be expected that the topic would arise up again. Rob Kaper kicked off the thread by saying: Please give some input on the following idea. For KConfig in 3.0 I would like to see the following changes: * allow "defaul" as readable value even for boolean entries etcetera, * add a "requirement" or good-practice recommendation that applications always save all possible entries in the config file, even those that are default * add a description QString to each key and group That way, users can be assured there are no "hidden" options in the code ever. Every configurable option will be in the configuration file. My concerns regarding this come forth from the removal of "Fade out applet handles" from kcmkicker. Since it has no GUI entry and is not present in the default saved configuration file, there is no way to know whether the option exists but to be familiar with the code. Proposed changes would also make it fairly easy to add "Advanced options.." buttons to KControl as that could be a small program reading all the entries, defaults and descriptions. Launching Kate with the appropriate rc file and a special highlight mode would probably suffice. Another option would be to switch to XML based configuration files, which allows us to store possible values in a DTD and have a generic "RC Editor" (or a Kate plugin) for advanced features. Such a config file editor would probably be the best option to keep KControl simple yet allow power users to tweak all advanced features of a program. Simon Hausmann had some concerns with writing out each and every config option, saying: There's one disadvantage with always writing out configuration values: They get written into the local config and if you do that for each and every entry you 1. get full blown config files in the user directory, containing redundant information 2. loose the ability for a system administrator to change global values, because the global changes never get applied to the apps as for each field there is an entry in the local file. What we actually need for a kconfig editor is the meta information of which field having which type and some documentation around it (that's an argument for not putting the description in the kconfig file -> you might want to translate the description) . Maybe we shouldn't try to put this information into the config files but into a separate file/database. Martijn Klingens noted that most applications already write out all possible configuration options regardless of whether they are set to the default value or not. XML files were suggested but decided against as requiring too much time and resources to parse efficiently. On a slight tangent, Charles Samuels suggested: we should eliminate the obvious lack of OO safety in KConfig and always explicitly set a group when accessing a key. My personal favorite way is a group(QString) function that returns a temporary KConfigGroup. In other words config->group("Some Group Name")->readEntry("Some Key"); Several others agreed that this was a good idea and should deffinitely be implemented in this manner. In the end many questions remained unanswered. It will interesting for both developers and users alike to watch what happens to the configuration infrastructure in KDE 3.0. 5. Konqueror Showing Progress 26 Jul 2001 - 28 Jul 2001 (5 posts) Archive Link: "progress patch" Topics: Konqueror People: Dirk Mueller, Tobias Anton Many have been watching Konqueror's tremendous progress towards becoming an excellent web browser. So it's slightly ironic that one of Konqueror's weakness is accurately displaying the progress of downloading and displaying a web page. This is changing however thanks to a patch Dirk Mueller has been working on. Regarding this patch, Dirk said, "as I noted earlier I'm currently working on fixing the progress information. What I thought about is putting all the ugly logic that maps the heap of information about the ongoing actions into a 0-100% value in khtmlpart and make it emit a signal that GUI frontends can connect to (void progress(int percent) for example)." He went on to ask for input on some of the aproaches he was taking. After a lengthy technical discussion on the finer points of how and when to let the GUI know about various events occuring from within khtml, Dirk posted a patch saying: this is a prelimiary version of working progress information. It has a few defiencies currently (one of them is that it is not well tested). Namely there are: * speed information is broken, see the FIXME in the patch. I'm not sure if I should accumulate the speed info of all jobs running, or just of the main HTML page. if the latter, a slot that converts the unsigned long to an int should suffice. or ? * it does now no longer only count images, but instead all referenced objects. I did not yet adapt the i18n-strings to reflect that, anyway as images are the majority of objects this should be not a big issue * accumulating information over subframes is not yet implemented. I don't know how to find out if I'm the "topleve" frameset and how I can find a paretn khtmlpart if I'm a FRAME. Simon ? Besides that, the patch has also some other minor fixes and changes, as * fixing the broken baseurl handling we had all over the place. fixes the referrer string. * cleaning the related signatures up. * implementing attribute width for