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

KDE Traffic #57 For 2 Jul 2003

Editor: Russell Miller


Table Of Contents


Not a whole lot of stuff this week, as usual, but the stuff that there is is a little more interesting than usual.

Sorry it's late this week. I have a good reason but I'm not going to share it.

This is issue number 57 - that means it's issue number 10 under my August... rule? leadership? guidance? bull-pucky? Anyway. I rock.

Did I mention how modest I am?

Happy Independence day to our American readers. Sometimes I wonder if that particular holiday is apropos anymore, but hey, it's a day off work, and it's supposed to be hot with a chance of thunderstorms here, so maybe I'll go feed the ducks and the fish at the local pond. How are you going to spend it? (Non-american readers can also reply, but I bet the responses will be much more boring!)

No submissions yet in the "What Are Marc's Priorities" contest. If I don't get submission, I'll have to make it up myself. And they won't be nearly as funny!

Mailing List Stats For This Week

We looked at 641 posts in 2593K.

There were 245 different contributors. 113 posted more than once. 84 posted last week too.

The top posters of the week were:

1. KDE Release Plan take 2

15 Jun 2003 - 19 Jun 2003 (33 posts) Archive Link: "RE: KDE 3.2 Release Plan notice"

Summary By Russell Miller

People: Martijn Klingens

Martijn Klingens stirred up the hornet's nest again with:

Can't we make the RCs this time what they are supposed to be, i.e. candidate tarballs that to the best of our knowledge are suitable for release ?

This means the following changes in the schedule:

1) What is now called RC 1 in week 46 (November 9th) will be the "Final Beta" instead. We all know that that release results in quite a bit of showstoppers and can't possibly be called a 'release candidate' after all.

2) Instead of releasing RCs weekly we release them whenever we have no known showstoppers left. This means there are no fixed dates for the RCs, they are dependent on the amount of issues found.

3) The first RC that does not result in reports of new showstoppers will be used UNMODIFIED as the release tarball. Well, one change: add a CVS tag, but a diff on the code between the final RC and the release should be empty.

This will probably result in a sligthly longer period between the final bet and the release, but it also avoids most of the chaos around the way too arbitrarily chosen dates for shipping "release candidates" that are everything but release-worthy. It most likely also results in a more stable initial release, though it probably won't be enough to make the initial release of the quality that we until now reached in the x.y.1 point releases

Looking at past releases all .1 releases are what .0 should have been. This can be achieved by releasing the final RC as RC, and branching CVS, but only release the .0 roughly a month after the final RC off the branch. Another option is to change our definition of 'show-stopper' to include more bugs so more need fixing before release too.

As the one thing that I can say with absolute certainly about the KDE community is that they love to talk, there was a predicted storm of responses. Most of the contention seemed to center around whether Martijn has a valid point or whether the boat simply shouldn't be rocked. There was no resolution. Discuss among yourselves. Here's a topic.

2. KDE 3.1.3

19 Jun 2003 - 22 Jun 2003 (12 posts) Archive Link: "KDE 3.1.3"

Summary By Russell Miller

People: Dirk Mueller

Dirk Mueller stated that he wishes to tag 3.1.3 by Monday, June 30th, and asked if there were any objections. There were a couple. It was not apparent whether Dirk pushed back his intended date.

3. Hex Editor Widget

20 Jun 2003 - 22 Jun 2003 (18 posts) Archive Link: "Hex Editor Widget"

Summary By Russell Miller

People: Reinhold KainhoferRussell MillerFriedrich W. H. Kossebau

Disclaimer: As I have posted to this thread, I have sent my intention to cover it to the kc-kde mailing list. As there were no objections that I am aware of, I am doing so.

Once upon a time, Reinhold Kainhofer asked:

Is there any widget for KDE to edit arbitrary data in hexadecimal mode?

I only found the class CHexViewWidget in kdeutils/khexedit, but unfortunately CHexBuffer only seems to work with data coming from files, but not with data that already exists in memory in the form of a unsigned char* (and has never been in a file).

Are there any other widgets for hex editing? Or is there any way to make CHexViewWidget work with data from a unsigned char*?

The reason I need this is because I'm implementing a generic database viewer/editor for KPilot, which lets the user view and edit the raw data of records and databases (similar to the application RsrcEdit on the handheld).

To which I replied, " I would also be interested in such a widget - one of the apps that I have written, kbview, would benefit greatly from such a widget. "

To which Friedrich W. H. Kossebau responded:

Hehe, that is funny: At the very same time this year I started such a program like kbview myself, partly out of the same reason you mention on your page :)) (Perhaps we can cooperate in the future, though by now I will concentrate on the hex widget). Any actual code (since march 30th) or screenshot? And there arose my need for this hex edit widget, too. Well, I will deliver this part :)

Which is definitely good news - a general purpose hex editor widget, in my unbiased opinion, is a very nice thing to have around.

Friedrich hoped that the work would be completed in two or three weeks, at which time it has been requested that he add the widget to kdeui.

(ed. [] The word "unbiased" was a joke, for the humor impaired. )

4. System Modules for Control Center

21 Jun 2003 - 23 Jun 2003 (29 posts) Archive Link: "System Modules for Control Center"

Summary By Russell Miller

People: Dik TakkenBenjamin MeyerPhillip ScottChristian Mueller

Dik Takken asked:

I was wondering what work people are doing to create Control Centre modules for system administration tasks that have nothing to do with KDE itself, like:

- Start/Stop system services like cups, smb, cron etc
- insert/remove/list kernel modules, query/set module parameters
- configure ssh/telnet servers
- configure network devices
- configure scripts attached to hotplug events
- etc

I would like to know if people think such functionality should be present in KDE Control Centre, or if a seperate System Control Centre should be created for such tasks.

I am thinking about developing KDE apps to do system admin tasks, so please tell me who is doing what.

With regard to network devices, Benjamin Meyer said, " That would be me. Check out knetworksetup in kdenonbeta. :0) The problem is that it only works for Debian right now. Every distro does networking its own way. I am speaking to LSB about getting something more concreate put down. "

And Phillip Scott said:

I think in principle, this is a marvellous idea, but the problem is, this is not nearly as simple as it sounds. Every distribution keeps its configuration files in a slightly different place, the boot scripts being the least standardised. A few distribitions do make some efforts to add modules like these; for example redhat includes an interface to configure it's ftp daemon. The kernel modules stuff could certainly work, and I think is a good idea - and if you can find ways of achieving the rest in a non-distro specific way you are brighter than me!

Perhaps it is time we tried to standardise these things across the linuxes. (And rember, kde does not have to mean linux, so these tools would be redundant for a few users, albeit I assume a small minority)

To which Christian Mueller replied:

You could try to handle that with distro / OS profiles that contain the locations of those files. But you would also have to consider distro and/or application *version numbers* because those things tend to change from time to time. This would require quite a few maintenance work on top of the actual coding.

But there's something else: The professional admins I know tend to write/adapt their own init.d/* scripts so these new modules should also be customisable and be able to use the logic in the shell scripts. BTW, they're not too fond of graphical tools anyway. But that's a different matter ;-)

And you're absolutely correct, this is the classic area where distro makers put their effort, so almost every distro has its own incompatible set of config tools. The question that'll come up immediately is whether the KCC module plays together with those tools (e.g. they can be used interchangeably and don't overwrite each others' changes)

Other messages went on in the same vein. There was general agreement that this will be a very difficult task.

5. Privacy Control Center Module

22 Jun 2003 (29 posts) Archive Link: "Privacy Control Center Module"

Summary By Russell Miller

People: Ralf Hoelzer

Ralf Hoelzer said:

I was missing a quick way in KDE to clean up all privacy related traces, such as cookies, caches, clipboards, command and URL histories, stored passwords etc.

So I have started to write a small control center module that offers these actions in a central place, sorted into different sections. It would fit nicely into the existing "Security & Privacy" category.

Here's a screenshot:

Not all apps are as nice as Konqueror and offer the required functionality through dcop. I tried writing the config files directly, but apps like kdesktop/minicli write the configuration back on exit, which makes it almost impossible to clear things like the "Run Command" history. If nobody objects, I would like to add some dcop functions in these cases (such as kdesktop) to enable this. I definitely think dcop is the best way to perform these cleanups, the other ways I tried are pretty ugly hacks :).

Does anybody think this privacy kcm module is a good idea? If so, I can make the code available and add more functionality and the required dcop calls where they are needed.

There was general agreement that this is a good idea. The rest of the thread discussed implementation details.







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.