KDE Traffic #55 For 19 Jun 2003

Editor: Russell Miller

By KDE Promo Team

Table Of Contents

Introduction

Yes, this week's was very late. There are many reasons. Work has been unusually hectic, rehearsals have started in the community theater, etc., etc. To make up for it, I'm going to put something special in the newsletter this week.

Wouldn't you know it, the kde3.2 release thread has fired up yet again. I'll cover that incarnation of it as well when it quiets down if there's anything interesting to cover.

Thanks to Fabrice for contributing this week.

Mailing List Stats For This Week

We looked at 807 posts in 3165K.

There were 243 different contributors. 117 posted more than once. 76 posted last week too.

The top posters of the week were:

1. dropping kmidi?

27 May 2003 - 5 Jun 2003 (18 posts) Archive Link: "dropping kmidi?"

Summary By Russell Miller

People: Stephan KulowRussell Miller

Stephan Kulow asked on kde-core-devel:

I need some advise from those that know. http://bugs.kde.org/show_bug.cgi?id=58995 is yet another bug for kmidi. There are 19 bug reports for it and I can't see any activity in the code base since 2000.

I'd like to move to kdenonbeta. Is there any reason to keep it I don't see? I played my last midi file in the last century, so I can't say ;(

The responses were varied, and discussed the appropriateness of using timidity, where to find the latest version of timidity (hint: sourceforge), ALSA, and software/hardware synth. Some were in favor of dropping kmidi. Most seemed ambivalent about it.

(ed. [Russell Miller] If no one else steps up to the plate, I will take over maintainership of this. I am a musician myself and I would like to see kde's midi support continue to be developed. I will check back in a week or so. )

2. IR controller project

2 Jun 2003 - 6 Jun 2003 (30 posts) Archive Link: "new kde project"

Summary By Russell Miller

People: Gav Wood

Gav Wood said on kde-core-devel:

i've recently created, developed and completed (as far as an os project can be...) an infra-red remote control (ir-rc) subsystem for kde using lirc.

the actual subsystem contains two main projects; "irkick", implemented as a kded daemon and it acts as the ir-rc server and communicates via dcop to any other processes that need to know about the ir capabilities of the computer. it also features as a dcop "mast", carrying out dcop tasks in other applications as and when the relevant buttons of remote control(s) are pressed.

the other project "kcmlirc" is a powerful control panel applet that allows configuration of irkick's actions. buttons on remote controls may be bound to any dcop function in any kde program. profiles of common programs may be used to give a user-friendly representation of the dcop functions, not exposing the raw dcop function prototypes/parameters/etc. so far three profiles are available (kalbums, noatun, kscd), however creating them is a _very_ simple task as they are written in simple xml (and have a howto and dtd).

remote controls also have profiles to give them descriptive names (though kcmlirc will fallback on the rough lowercase-only, no spaces names of lirc if no profile is available). again xml allows simple and easy creation of such definition files.

modes are used to allow the same button to do different actions in different circumstances, and are implemented in a highly flexible manner to give the user the ultimate power of a finate state automaton if necessary (though the simple interface allows a relatively shallow learning curve).

it uses lirc, a linux-only infra-red hardware kernel-module set, however it is designed with a solid and simple api to support other architectures transparently if and when they become available.

as it is finished my only plans are to extend the lirc configuration so that it provides a central place for all ir-rc configuration of the system.

the whole code as it stands is checked in at kdenonbeta/kdelirc --- it would be cool to get it in a relevant kde package (perhaps kdebase or kdemultimedia) for 3.2.

there are some screenshots for your perusal at http://www.indigoarchive.net/gav/kcmlirc/

Responses were generally favorable - the biggest discussion was whether to put it in kdemultimedia or kdeutils. Kdeutils won, at least by number of votes. There was also an interesting subthread giving information on how to program a dcop-compliant app.

3. UI Abstraction Proposal

2 Jun 2003 - 4 Jun 2003 (20 posts) Archive Link: "[PATCH] UI abstraction proposal (partially only)"

Summary By Russell Miller

Andreas Gungl got the ball rolling on a first attempt to begin abstraction of the kmail core from the UI. There was quite a bit of comment about implementation details, but out of this thread came a much clearer idea of what the goal is as far as separation of the UI from the core.

I will not go into all of the implementation details, except to say that The idea of using DCOP figured very strongly. The reader is highly advised to read the thread if further information is desired. I did find it very interesting, however, and anyone who is interested in how kmail is beginning to evolve would find this thread helpful.

4. A happy user

8 Jun 2003 - 10 Jun 2003 (2 posts) Archive Link: "Simply want to say thanks"

Summary By Russell Miller

People: Markus Meissner

Since I am always a sucker for happy users, Markus Meissner had this to say on kde-pim:

I just want to say thanks to all of the kde-pim developers, you have made a great job! I am using KMail and KOrganizer, I have synchronized all my Outlook-data to linux with my palm (a lot of), no data loss, works great! Thanks!

The lesson here being, you like kde and send us a note saying so, and you may become famous.

Or is the lesson that you shouldn't tell us you like KDE if you are a felon on the run...

5. KDE enterprise gets attention

 Archive Link: "KDE enterprise gets attention"

Summary By KDE Promo Team

Topics: Promotion, KDE in the Enterprise

People: Kurt PfeifleRoberto Selbach Teixeira

It started when Kurt Pfeifle posted on the wrong list

Sorry, I posted this only by accident to this English-speaking list.

But nevertheless the thread went on ... until the following remark from Roberta caught my eye.

btw, I think it's time for KDE::Enterprise to come back to life... I'll try to reach Jono to see if he's got any thoughts about it. Anyway, I'll volunteer to carry on if he's got no time left.

Kurt saw the outcome of his faulty submission to the kde-promo mailinglist:

Good offer!
Thanks,Kurt

6. Not enough time for KDE

 Archive Link: " Not enough time for KDE"

Summary By KDE Promo Team

Topics: Promotion

People: Roberto Selbach TeixeiraRalf NoldenRussell Miller

Roberto Selbach Teixeira also made another announcement on the kde-promo mailinglist:

KDE has been a great experience in my life and I am very proud to have been a small part of such a tremendous project. It has given me nothing but great experiences and memories.

Unfortunately, I think it is time for me to actually realize what in fact had already become obvious quite some time ago: I do not have enough time for KDE anymore. I haven't been able to contribute a single line of code for _several_ months now. I am back to the academic life of a student, my job is demanding more and more time and, well, I am getting married, so time is kind of short :)

I would appreciate if you could remove my name from the contact list on the project's site and add Helio Castro instead. I sort of brought him to the project to help me and suddenly he's doing so much work, both in terms of coding and in advocacy! I guess I was a good mentor ;P

Also, Knode needs help. Reports are being filled by the hour (literally) and some of them might be better fixed. So if you care about Knode, please take a look at the bug list at bugs.kde.org whenever you find some time.

Some people thanked him and responded that he would surely return because KDE is very much addictive. Ralf Nolden concluded the thread by saying:

Thank you very very very much for your contributions. You will remain a part of KDE because sooner or later you probably will have a look what's going on and answer at least some mails and questions on irc :-)

We wish you and your girfriend a happy marriage and we hope that your kids will enjoy the Kinder Desktop Environment as well :-))

Roberto and Lisiane Sztoltz will get married on July 12th. Lisiane is the Brazilian i18n team coordinator, so it's all in the family

(ed. [Russell Miller] I'll keep my mouth shut. Oops. Too late. )

7. The promised treat.

 

Summary By Russell Miller

People: Russell Miller

Ok I promised you all a treat for being late. It's hard to decide what to get the discriminating kde-traffic reader who has everything. A nice large jar of spaghetti sauce comes to mind, but the shipping would be horrendous. I could make an abortive attempt at humor, but instead I think tonight I will wax philosophical and copy a slashdot posting that I made a few days ago. I know that it's not much, and it may not even be considered a "treat" by some. Just consider it me trying to share a bit of myself with you all, and if you don't like it, you can feel free to skip the article. I think the developers among you may appreciate this. (and yes, I did write this.)

Re:Do younger minds absorb quicker? (Score:5, Interesting) by Anonymous Coward on Friday June 13, @02:34PM (#6193214)

I am a pianist. I would say that the only advantage that a younger person (read: child) has on an older person as far as pianism goes is that they have a head start.

I personally find the young people (especially the child prodigies who play) to be technically astonishing but dead in terms of the more esoteric parts of a performance. It takes a certain amount of life experience to know how to play with real feeling and maturity.

Being a programmer as well, I can state with absolute certainty that the same thing is true with programming. There is an artistry to programming that beginners lack. Heck, it took me 8 years to find it. And that artistry can allow you to write stabler, more efficient code.

Trying to explain... When one starts out on the piano, one sees individual black blobs on the page. Those blobs eventually start to form notes, and you learn the notes. Just as when you program, you learn the syntax of the language. And with a little trial and error, you can write a program that barely works, just as you can play music that sounds halfways decent.

But then the notes become chords - the chords become phrases, and the phrases become sections. And once you start to see the music in terms of phrases and sections, you need not worry about implementation details (what is this chord, how do I articulate that) and you are free to focus on the higher artistry of the music - what is this trying to get across, what do I want to invoke on the listener...

And once that happens, you have a self-consistent piece of art. Every piece relates to the other, in an unbroken fashion, throughout the piece - from the first note to the final chord. I don't care if it's 20 minutes long - you can still make that happen.

In terms of programming, this means that every module interacts well with all of the other modules, the code is clean and well-written, there are very few to no cases where errors are unhandled or a module will get unvalidated or unexpected input. The code is stable, and provably so.

Finding a pianist who can play the notes is cheap. Just as finding a programmer who can write code is cheap. They are a dime a dozen, and frankly, I'm not sure I would hire one. Finding a pianist who is a musician, or finding a coder who is an artist - that is a rare and precious find indeed.

Hope you like.

 

 

 

 

 

 

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.