Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

KDE Traffic #6 For 13 Apr 2001

By Aaron J. Seigo

Table Of Contents


Welcome to KC KDE! Much of this week in KDE development was spent in a code freeze in preparation for an alpha release of KDE2.2. Only bug fixes were being applied to the CVS tree and new major developments were to be held off until the release of the alpha tarballs. With the attention of the developers fixed on the little details, the discussions on the mailing list were correspondingly light and to the point. However, we now get to look forward to both a preview release of 2.2 for general testing as well as the usual addition of new features that occur after any code freeze. A "thank-you" goes out to all involved in the KDE project for not only keeping to a timely release schedule but also for the attention being paid to the small things!


1. KControl Module for KDM
2 Apr 2001 - 5 Apr 2001 (7 posts) Archive Link: "please comment: kdm control module"
Topics: KControl
People: Oswald BuddenhagenRik HemsleySven NiednerTorsten Rahn

While working on the KControl module for the new and improved KDM X login manager, Oswald Buddenhagen asked for input on the kde-look list saying:

as i want to make everything configurable from the module (no nasty xdm config files any more :-)), the amount of options will become overwhelming. so what do you suggest?

as we all know, nested tabs are bad style (hmm ... why? an intuitive hierarchy should suffice, no?). putting everything in one "tab line" is inacceptable, too (esp., as i'm already hardly able to find distinct hotkeys).

i thought about making a whole kcontrol submenu. this would also emphasize the fact, that the whole kdm setup contains many duplicate options from other modules - but for no user. otoh, the kdesu stuff had to be done for every single submenu, if we find no sensible solution to group it (hmm - maybe, invoke a second kcontrol instance with only the kdm menu options enabled?).

ideas? comments?

Torsten Rahn suggested that perhaps this functionality should simply be rolled into the theming capabilities and left at that. However Oswald pointed out that there are simply too many things outside of the scope of theming involved in setting up KDM. He listed several examples, including session types, Xaccess and Xserver configurations, and password control.

On the kdesu and tree depth points, Rik Hemsley said, " AFAIK the kdesu dialog should be shown only once, because the password is cached for a while. Perhaps not... you might want to ask on core-devel about that point. I would hope someone will answer that :) We've been trying to keep the tree depth of kcontrol down, but I don't see a way around using larger tree depths in some cases. If the other choices are nested tab boxes or long tab lines, then we have no real choice but to go for extra tree depth." Sven Niedner pointed out that only asking for the root password once is a bad idea saying, " typing in the root password is always an alarm sign: "Now you act as an administrator, and what you are doing might possibly affect other users.", and it should make people think twice about what they are doing." Oswald agreed with this and made a general shopping list of his conclusions. The new kcontrol module along with the improved KDM will definitely raise the bar for X login programs.


2. KDE Games Gets a New Maintainer
3 Apr 2001 - 7 Apr 2001 (13 posts) Archive Link: "[Kde-games-devel] Fwd: continuity between games"
Topics: KDE-Games
People: Martin HeniAndreas BeckermannJosef Spillner

On the games-devel list, it was pointed out that the various games included with KDE are not very consistent, in sharp contrast with the overall consistency of the rest of the desktop. One example given was the keyboard shortcut to start a new game, which in some games is F2 and in others Ctrl-N. Martin Heni agreed that this needed attention saying, " It would be useful to have this more consistent. Maybe someone wants to compile a guide how to name things properly. Of course this would be a subset of the normal KDE guidelines. But there are some things which are game specific. Anybody volunteering?" Later on in the discussion Andreas Beckermann volunteered saying, " Yeah - I have holidays :-))) I volunteer to do so, although it will need quite some time as I can start only next week. BTW: Do we have some native speaker around? I need test readers... Oh and I will *try* to keep the outlook of the style guide on - does someone have information on how to achieve this?"

Josef Spillner had a different opinion on the continuity issue, as he explain saying, " As (hopefully) KDE games are getting more complex and diverse it would be very difficult to handle this. I would agree that the keyboard shortcuts could be changed for the already existant ones (if someone with CVS access volunteers), but there is clearly a difference between e.g. KOffice (which must provide a consistent user UI) and usually games, which are free to follow their own rules. I would even appreciate more KDE games which don't look like KDE/Qt on every board and menu." The discussion then turned to distinguishing between small games that would fit within the KDE games package and should therefore share some consistent features and those that are beyond the scope of KDE-games and should remain separate projects free to do things "their way" even if they do use the KDE libraries. Andreas pointed out that the true challenge at hand was maintenance, saying: "That is a problem of the games: most are (nearly) not maintained anymore. It is quite simple to do but someone has to do it (which needs some time if you are not familar to the code). KMahjongg is a good example here: it was once crashing on startup (before KDE 2.0 IIRC) for quite some while - I fixed this in a more or less ugly hack and could not even reach the author by his email address... Perhaps we need a new package maintainer or so?" By the end of the discussion the honor of KDE Games maintainer had been bestowed upon Andreas. Congrats Andi! We look forward to your leadership in this part of KDE development.


3. .rc Files, DCOP and Konqi Debugging
4 Apr 2001 - 6 Apr 2001 (5 posts) Archive Link: "DOM and konqueror"
Topics: Bug Tracking, DCOP, Konqueror
People: Gioele BarabucciDavid Faure

Gioele Barabucci asked, " Is possible to ask konqueror to print the DOM tree (Level 1) of the current page? How? I do not see any menu to do this..." While an interesting question in and of itself, the answer provided by David Faure shows just how powerful the KDE framework is: " Uncomment those lines from khtml_browser.rc, to make the debug menuitems reappear : <!-- <Separator /> <Action name="debugRenderTree" /> <Action name="debugDOMTree" /> --> " .Daniel Andor then asked if these debugging actions can be activated using DCOP, to which David Faure said, " Definitely. Use kdcop to browse the available objects for a konqueror process (or other), the qt/dcop bridge provides access to all Qt objects, including the actions."


4. Sockets and Cross Platform Fun
7 Apr 2001 (4 posts) Archive Link: "ksize_t weirdness"
Topics: Operating Systems, Sockets
People: Thomas LeitnerThiago MacieraRob NapierOswald Buddenhagen

Since the various platforms that KDE supports do not all use a standardized datatype for socket handling, making the new advanced socket code compile cleanly across all platforms has been tricky. The saga continued this week when Thomas Leitner said:

All source comments say that ksize_t is supposed to be the type of the last parameter to getsockname. This is size_t on my platform. The same size_t is used for all other system calls like getpeername, accept, etc. etc. Now I've got two problems with this:

  • the configure script does *not* automatically pick up size_t as the correct type for getsockname. Instead it uses int. I've tried to change aclocal.m4 and acinclude.m4 to correctly pick up size_t for ksize_t but it didn't work :-(
  • When I manually change "int" to "size_t" in config.h, I get ... errors

Oswald Buddenhagen stepped up and volunteered to handle both the configuration handling as well as moving all remaining instances of ksize_t to the platform native socklen_t while ensuring that all public interfaces used KDE's ksocklen_t. He then posted a patch for those who were having problems to try out. Thomas reported success and Rob Napier posted a small patch to Oswald's patch to make things compile properly on Solaris. Thiago Maciera looked over the original patch and said, " I think that system calls should be cast to socklen_t and that whatever we defined would be something consistent. I suggested keeping ksocklen_t so that we know what that is about and that that has to be cast to socklen_t for the system calls. And, if in the future we need to change something on that again, finding ksocklen_t is easier than identifying what "unsigneds" are what. Think of the POSIX guys redefining again the meanings." Oswald replied that ksocklen_t is indeed used throughout the public interfaces and that the native datatypes are only used internally to the class.


5. Extending Applications with DCOP?
9 Apr 2001 - 10 Apr 2001 (25 posts) Archive Link: "External actions proposal"
Topics: DCOP, UI
People: Roberto AlsinaWaldo Bastian

After experimenting with DCOP, KDE's interprocess communication facility, Roberto Alsina said: " I feel there is a need to take DCOP to the next level. Right now, you can script your apps. But that's not enough. Because you can not really EXTEND your apps. How about this. Imagine a repository of scripts that use DCOP interfaces. Those scripts are indexed according to where they fit. I don't quite understand how, yet, but in the crudest way, imagine "scripts for konqueror", "scripts for kant" and so on.Now, imagine that before building the UI from the XML files, you contact this repository, and get a list of actions, each action being a call to one such script. This makes those actions available to the UI builder, can make them appear as entries in the menus, as buttons in the toolbars. This lets the user/programmer EXTEND the apps without having to rebuild them.This lets writing proof-of-concept features simpler, and they later can be incorporated in the app. This, really, doesn't seem all that hard to do, and I'm volunteering ;-)"

After clearing up some general confusion regarding wether or not Roberto meant for the repository of scripts to be local or remote (he was in fact thinking of a local repository) Waldo Bastian said, " I don't like the "contact this repository" part if that adds anything like connecting to another process, stating a file, reading a file, listing a directory or a combination of those things. E.g. it should be a solution that hooks into one of the too many files that we read already. For example the XML file that describes the UI, but I guess the kdeglobal config file, or the application specific config file would be fine as well. (Since we read those already anyway)" Roberto provided more details regarding his idea saying, " I was thinking more of a persistent process. More or less like this: You add the action's name to the XML UI file to put it in the menu. When the user runs the action (sorry, I don't know how to say it ;-), the action just sends a DCOP message to this "external action server", passing the action name. That server then runs the script somehow."

There was further discussion regarding how such a thing could be implemented and how it could be used. It will be interesting to watch for this sort of functionality in the future.


6. KDE 2.2 Alpha 1
9 Apr 2001 (6 posts) Archive Link: "KDE 2.2alpha1 planned for this week!"
Topics: Release Schedule, KDE 2.2, Debian
People: Waldo BastianNavindra UmaneeAndreas PourThiago Macieira

KDE Release Meister Waldo Bastian announced: " For this week KDE 2.2alpha1 is planned to happen. For that to be successfull I would like to ask everyone to make sure that KDE compiles on all platforms. You might also want to fix those few big bugs you know about :-) Most importantly, please _NO NEW CODE_ this week. Code added just before a release tends to cause a lot of problems. If you have any major changes or new features pending, please wait till next week... If everything goes well, we will have 2.2alpha1 available as tarball on our ftp-site this friday. Binary packages are then expected to appear during next week. In related news: We are also looking for someone who wants to make binary RPMS for RedHat based systems."

Navindra Umanee noted that it did not build cleanly on Debian Slink and Thiago Macieira provided a patch to fix this. Andreas Pour volunteered to provide RPMs for Redhat 6.2 to fill in that gap. Waldo later announced that all the modules had been successfully turned into tarballs for packaging as KDE2.1alpha1 with the exceptions of kdevelop, kdepim, kdesdk and kdebindings.


7. KOffice, KDE 2.1 and Duplicated Code
11 Apr 2001 (14 posts) Archive Link: "Re: koofice/kpresenter"
Topics: KOffice
People: David FaureLukas TinklCarsten Pfeiffer

The image previewing in KOffice dialog boxes was ported to use the new previewing functionality in KFileDialog by Lukas Tinkl. The goal was to remove any need for duplicated code to perform this task within Koffice itself. However, the version of KFileDialog that this change required is only to be found in 2.2 development code. This means that KOffice developers and (eventually) users would need bleeding edge KDE code to run subsequent KOffice releases. David Faure was the first to note this problem and Carsten Pfeiffer suggested that perhaps it was time to up the requirement for KOffice development and have all the involved developers who were using KDE2.1 to upgrade to newer CVS based code. This was not a good solution however, as David pointed out saying, "It's actually more complex than that. We're supposed to make a first beta of KOffice 1.1 next week. If we want anyone to try it out, it should work with kdelibs-2.1 ! We've been battling for that since some time already, adding #ifdefs where necessary, etc. But this change breaks that :( Instead of me reverting it all, can one of you have a look at reverting to version 1.14 of (the last one which had WMF support), and making kpresenter use it again, but keeping the other changes that were done in this commit (some of which are unrelated cleanups afaics) ?" It was agreed that it would be necessary to bring back the old functionality to keep KOffice compatible with 2.1 libraries.

Another question raised was whether or not KFileDialog supported previewing WMF files. Carsten noted that it did not and that adding WMF support to KImageIO would allow previewing such files. This led Lukas Tinkl to note that there were some rather large amounts of code duplication surrounding WMF support, saying, "But we have a little problem still; KOffice contains a WMF library, and in addition, KPresenter (still) uses it own (qwmf). Wouldn't it be better to move kwmf to KImageIO and port KPresenter? ... Wow, KIllustrator contains its *own* copy too! So we now have three non-identical copies of the same stuff... " David Faure noted that WMF support wouldn't fit in KImageIO since it is a vector format and KImageIO it bitmap based. On the matter of the code duplication David said: "KWMF still needs work before it can replace qwmf. Shaheed started it, but hopes someone else will take over, or will finish later - the priority isn't huge. I think what we need is simply to be able to extend the preview widget in koffice, currently using qwmf, and later porting to kwmf."

At this point, Lukas made an interesting discovery which he noted saying, " If it doesn't hurt that much, I'll revert KPresenter to use the original preview widget tomorrow. It apparently supports WMF files, opposing to what I thought before. Well, I was mistaken because the preview widget *did* support WMF but KPresenter's code did *not* make use of it :-) That's why I originally replaced it with the one coming from kcontrol/background, which I thought was better. Ufff...." Lukas also noted that KWord has its own copy of the previewing code and that he was interested in working with Shaheed on getting KWMF completed and all the KOffice code ported to it to avoid the massive duplication that currently exists.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.