KDE Traffic #69 For 30 Nov 2003

Editor: Peter Rockai (mornfall)

By Henrique Pinto  and  Peter Rockai (mornfall)

If you like KDE Traffic, please consider making a donation to the KDE project. Visit http://www.kde.org/support/ for details.

Table Of Contents

Introduction

Welcome to KDE Traffic!

I would like to apologize for not issuing #69 last week. The school-related things hit me hard, and i was still sobering after a party last Sunday, without one summary written (all i held in hands were 2 summaries by Henrique -- but i thought it was too little to go public). So this is a double issue, covering both this and the last week. Once again, sorry for inconvenience.

Credit for this issue goes to brad for proof-reading. Thank you and keep up good work.

This issue covers the following mailing lists: kde, kde-devel, kde-core-devel, kde-extra-gear, kde-usability, kde-i18n-doc, kmail, kde-pim, kde-optimize, kfm-devel, quanta, kde-bindings, kdevelop-devel and koffice-devel.

We hope you will like this issue!

Mailing List Stats For This Week

We looked at 1799 posts in 6455K.

There were 392 different contributors. 221 posted more than once. 149 posted last week too.

The top posters of the week were:

1. Feature requests -- the wrong way [kmail]

25 Nov 2003 - 27 Nov 2003 (3 posts) Archive Link: "HTML"

Summary By Peter Rockai (mornfall)

Topics: KMail, Bug Reporting

People: Jim SimonIngo Klöcker

This thread started when Jim Simon posted his wish to developer mailing list (which is not the best idea, you know -- there is bugs.kde.org (http://bugs.kde.org) page for this. He wrote: "When will KMail come with native HTML writing support? I'd really love to be able to write the same kind of emails in KMail that I do with Outlook for Windows." . Ingo, somewhat upset, but still polite, answered: "When it's ready. Not in KDE 3.2. And please refrain from sending such annoying messages to our mailing list in the future. Thanks for understanding." . This was followed by a short period of silence. After about a day, Ingo posted his freezingly polite reply: "Dear Jim, you are not in the position to demand anything from us. If KMail doesn't serve your needs then please consider using another email client." to Jim Simson's off-the-list e-mail:

Hey Fuckhead,

How long has this been the most requested feature? Get off your ass and get it done. And please refrain from sending ME your trifling criticisms.

Judge yourself. Well, how was this supposed to work again? I get an excellent piece of software for free and then go and call its author names just because i don't like the way he works. "No good deed will remain without punishment", someone said, and was probably right. If i got such an e-mail, i would reconsider my future work for the so-called community. See how well it works? Work in, shit out. Ok, i am slightly pissed off. Honestly, it works most of the time. But users like this one make me question my faith in Open Source. I would like to express my support to Ingo and all the KDE developers, who must face this user-rudeness and thanklessness. There are still people, who appreciate your hard work. I do, definitely, and i believe many others do, as well.

Well, you may wonder why am i writing this... I have seen too many people turning cynical because of users like Mr. Simon. And i wish to do something against this.

2. How to add a KDevelop project to the KDE CVS Repository [kde-devel]

17 Nov 2003 (1 post) Archive Link: "Adding KDevelop Projects to the KDE CVS Repository new wiki"

Summary By Henrique Pinto

Topics: CVS, KDevelop

People: Gary Cramblitt

After some time trying to add a kicker applet he developed using KDevelop to kdenonbeta, Gary Cramblitt wrote a guide for doing that, and announced this in a message posted to the kde-devel and kdevelop mailing lists:

I've created a new wiki document entitled "Adding KDevelop Projects to the KDE CVS Repository". View it here:

http://kde.ground.cz/tiki-index.php?page=Adding+KDevelop+Projects+to+the+KDE+CVS+Repository (http://kde.ground.cz/tiki-index.php?page=Adding+KDevelop+Projects+to+the+KDE+CVS+Repository)

Eventually, this document will be incorporated into the KDevelop/doc tree. Please take a look at it. You can either edit the wiki directly, or if you don't want to create a wiki account, e-mail me directly or post comments in this mailing list.

The following are known issues:

1. I haven't addressed application documentation yet. If someone wants to take a shot at that...

2. I'm not sure about configure.in.in. Commit to the CVS repository or not?

3. The article addresses applications created using KDevelop 3.x. I don't know if the technique would work for KDevelop 2.x applications. Since KDevelop 3.x will be the "standard" with the release of KDE 3.2...

4. Does anyone know if the inst-apps file works in modules other than kdenonbeta?

Thanks for your input,
Gary Cramblitt

There were no replies in kde-devel.

3. Writing KDE Plugins in ECMAScript [kde-devel]

18 Nov 2003 (3 posts) Archive Link: "KJSEmbed and Kicker"

Summary By Henrique Pinto

Topics: KDE Bindings

People: Ian Reinhart GeiserJason Keirstead

Ian Reinhart Geiser was the one who sent this interesting message to kde-devel:

If you are interested in programming KDE applications with something other than C++. Have a look at KJSEmbed. Its starting to get stable enough that we can build KDE components with it. As an example we have built a kicker applet that can be extended in pure ECMAScript. For more details see: http://www.kdedevelopers.org/node/view/240 (http://www.kdedevelopers.org/node/view/240) . Note that this is a big thing because these same techniques can be used to build KOffice, KDevelop, and Konqueror plugins in pure ECMAScript.

Now this is interesting because VS any other scripting engine, this one is native Qt/KDE all of the way down, so it is fast and very intimate with KDE. We support all widgets that you can get in Qt Designer, KParts, KIO and almost all the KImageEffect effects.

http://xmelegance.org/kjsembed/ is the main page for docs and developer information. So take it out, kick it around and see if you can find/fix a bug today.

If you don't know yet, ECMAScript is a scripting language that is almost equal to JavaScript. The nicest thing about plugins written in scripting languages is the fact that they're "plataform independent", i. e., exactly the same plugin will work in any OS or distro, providing that you have KDE (and KJSEmbed, in this case) installed. Right now, if you compile, for example, a window decoration in Debian, it won't run well in Slackware. While it may be not wise to write window decorations in scripting languages (performance issues), it may be a wonderfull idea to do so for smaller plugins. With this in mind, Jason Keirstead replied, stating that " This could be a good replacement for the perl scripting plugin I had in progress for Kopete ( the HORRIBLE perl scripting plugin I should say )." In another message, Ian stated that he is working on making it easier to integrate the scripting engine into apps.

4. Kafka (aka Quanta VPL mode) progress [quanta-devel]

24 Nov 2003 - 25 Nov 2003 (5 posts) Archive Link: "Kafka progress"

Summary By Peter Rockai (mornfall)

Topics: Quanta

People: Eric Laffoon

Eric Laffoon posted a summary of his observations about kafka:

Hi all,
Nicolas, I just built Quanta and had a quick look at Kafka. I still have to try playing with it and seeing how well it creates pages with paragraphs, headers and such. However just having a look I'm rather impressed. A few days ago it didn't seem usable. Today I noted on my first look...

  1. Very fast and crisp loading a page
  2. excellent rendering while showing PHP tags (using split VPL/text view)
  3. PHP tag double click takes you to the PHP tag in text or highlights the area
  4. double clicking successive abutted tags highlights the whole group (odd behavior)
  5. clicking outside leaves the cursor
  6. cursor following in text mode is very good

I have to say the last one is rather interesting even for those people who have little interest in visual design. To see something on the page that needs attention, click on it and have your cursor delivered is a very cool time saving feature. Of course we're shooting for more ;-) but it's no small victory.

I'll report back after more testing. If other people on the list would test it would be good too.

So, if you have a little bit of time, go ahead and test kafka -- it is getting into shape. Eric proceeded to post a list of issues he ran into during further testing. He also stated, that his wife was impressed by kafka already (hey, Eric... where are such wives to be found? I might have some use for one ;p). Nicolas Deschildre replied, that meaningful work should be possible to do with kafka in about two months. Not sure whether he was kidding though :). But Eric seemed to believe him, so i will too, this time. Apart from this, various individual issues were debated in the thread, but i do not want to overwhelm you with such details. If interested, look into archives (see the link above).

5. Prelinking KDE -- libGL issues [kde-optimize]

29 Nov 2003 (3 posts) Archive Link: "Prelink and libGL.so : a tip"

Summary By Peter Rockai (mornfall)

Topics: Performance, KDE Tips

People: Leon Bottou

Leon Bottou posted a patch to make prelinking of KDE easier:

It is often quite difficult to use prelink with KDE because QT depends on libGL.so and libGL.so is often compiled as a non-PIC library for performance reasons.

The NVidia libraries are compiled this way, and I cannot recompile them in PIC mode for lack of source. Sigh.

This is frustrating because 95% of the KDE executables do not need libGL. Why not make QT load libGL when it needs it only?

The attached patch does this. It creates little stubs for all the openGL functions needed by QT. libGL.so is loaded with dlopen the first time one of these stubs is called. Otherwise the stub simply calls the required function.

Rough recipe:

I did it on my redhat9 box by loading the fedora source rpm (qt-3.1.2-7.fdr.3.src.rpm) and modifying the spec file to apply the pactch and tweak the makefile.

Result:


	[leonb@humbert SPECS]$ LD_DEBUG=statistics konqueror
	     25895:
	     25895:     runtime linker statistics:
	     25895:       total startup time in dynamic loader: 7824120 clock cycles
	     25895:                 time needed for relocation: 2653360 clock cycles (33.9%)
	     25895:                      number of relocations: 0
	     25895:           number of relocations from cache: 1940
	     25895:                time needed to load objects: 4555144 clock cycles (58.2%)
	

P.S. --
I am talking about Jakub Jelinek's ELF prelinker, not about my old objprelink hack. It does not work with gcc-3 anyway.

If you have this problem and think you can manage to get it working, then go ahead -- here is the patch (http://lists.kde.org/?l=kde-optimize&m=107007239305615&q=p3) .

6. KOffice 1.3 schedule changed [koffice-devel]

25 Nov 2003 (3 posts) Archive Link: "Current KOffice 1.3 plan"

Summary By Peter Rockai (mornfall)

Topics: KOffice

People: Lukas TinklKarl-Heinz Zimmer

Lukas Tinkl announced a change in release schedule for 1.3:

Hi,
the 1.3 plan has just been changed at the usual location. Some of you probably know, I've delayed (for the last time I promise) the release due to many bugfixes made to KChart internally in KDAB. I'm just waiting now for Karl-Heinz Zimmer to merge these changes back into KOffice CVS.

It currently looks like this:
December 2, 2003
Tag KOffice 1.3 final version (KOFFICE_1_3_RELEASE), create binary packages, test the tarballs.

December 10, 2003
The source and binary packages are uploaded to ftp.kde.org to give some time for the mirrors to get them.

December 11, 2003
Create changelogs, update the website

December 12, 2003
Announce KOffice 1.3

I hope KOffice 1.3 will be a nice XMAS gift for many people. :-)

For those, who don't know, where is the usual location: KOffice 1.3 release schedule @ developer.kde.org (http://developer.kde.org/development-versions/koffice-1.3-release-plan.html) .

Further in the thread, Diego Iastrubini asked, whether it is okay to commit i18n changes until the 2nd (of December), according to new plan. Lukas said it was, but remarked it would be better to finish all the commits the weekend before 2nd (that is today when i write this, the 30th November).

7. Removing "other office" thumbnails [koffice-devel]

28 Nov 2003 - 29 Nov 2003 (6 posts) Archive Link: "Removing "other office" thumbnails"

Summary By Peter Rockai (mornfall)

Topics: KOffice, Konqueror, Thumbnailing

People: Nicolas GoutteThomas ZanderLukas TinklNicolas Go

Nicolas Goutte proposed to get rid of "Other office thumbnails":

To work around bug#55657 (http://bugs.kde.org/show_bug.cgi?id=55657) (and its duplicate #59377 (http://bugs.kde.org/show_bug.cgi?id=59377) ), I propose to remove the file koffice/tools/thumbnail/otherofficethumbnail.desktop

The main problem of the "other office" thumbnails is that it is based on the filters. As our filters are far from bug-free, the problems of the filters are given here very raw, without having any chance not to do it. (When you know that a file crashes a filter, you do not load it, but the thumbnail will still be created. :-( )

Lukas Tinkl agreed, reminding Nicolas to not remove the source, but disable its compilation instead. Nicolas also remarked that this precaution will also fix bug 61885 (http://bugs.kde.org/show_bug.cgi?id=61885) .

Thomas Zander went on suggesting how to really fix the problem in konqueror, instead of working it around by disabling things:

Does that also fix the problem then when I have a .csv in my dir kspread opens a dialog asking me the table formatting? Very annoying when browsing a dir.

I think there are a couple of problems here, I doubt the buggy filters are to be blamed.

  1. konqueror should do some load managing of thumbnail generation; I have seen postscrip thumbnail generation cause the same problems.
  2. when a file fails to generate, for any reason at all, konq should register that and not retry the next time you enter the folder.
  3. filters should by default be started in an environment that has no X connection so popups and dialogs _can_ not appear.

Disabling the .desktop file seems like a good idea; but it does not really solve the problem, it works around it.

David; I hope that if you think the above is new and worthy for the konqueror hackers that you can forward it to them :)

Nicolas, responding to Thomas' 3rd point, commented: "Well, we had planned a batch mode for the filters. It is one of the things that nobody had the time to do for KOffice 1.3. :-(" . This only reminds us about the severe lack of manpower in KOffice. Anyone of our readers -- care to do something about this? It would be greatly appreciated.

8. KOffice toolbar icons improved [koffice-devel]

26 Nov 2003 (2 posts) Archive Link: "Proposal: Replacing Toolbar Icons in KOffice"

Summary By Peter Rockai (mornfall)

Topics: KOffice, Icons

People: Ben LambDavid Faure

Ben Lamb proposed to replace some of the current koffice toolbar icons with a more crystal-like alternative:

IMHO Some of the icons in KOffice could be prettier. Rohit Kaul has created some very attractive icons, published on KDE-Look, that I think would suit KOffice. Please see the screenshot:

http://www.kde-look.org/content/preview.php?file=7131-2.png

I'd like to propose replacing some of the existing icons with Rohit's versions, specifically the bold, italic, underlying, indent, justification, numbering and bulleted list icons.

Would anyone object if I did this? (Rohit has been BCC'd on this)

I'd consult kde-core-devel for icons that live in kdelibs.

David Faure was quick to agree, and Ben was seen committing the list and indentation icons into CVS. However, nothing was heard about other icons (alignment, type style, ...) since.

9. KDVI, KGhostview, KPdf Magnification [kde-usability]

17 Nov 2003 (3 posts) Archive Link: "KDVI, KGhostview, KPdf Magnification"

Summary By Henrique Pinto

Topics: UI

People: Luciano MontanaroWaldo Bastian

Luciano Montanaro pointed out an inconsistency in the placement of magnification buttons in KDVI, KGhostview and KPdf:

The toolbars for the three applications in question have a magnification "thingy" but each one is different:

kdvi has [+][-][100%]
KPdf has [+][100%][-]
KGhostview has [-][100%][+]

Personally, I'd like the [-][+] icons grouped, both on one side of the combobox, but anything consistent would be ok with me. The [-] icon should be to the left of the [+] though. Should I file a bug, for this, or is this message enough?

The message was enough. Due to the wonderful KDE framework, achieving consistency was really easy to do. Waldo Bastian was very quick in doing that, and minutes later he announced that the problems were over and the toolbars of those apps were now consistent.

10. Reply behavior in KMail [kde-usability]

29 Nov 2003 - 30 Nov 2003 (29 posts) Archive Link: "[RFC] Reply behavior in KMail"

Summary By Henrique Pinto

Topics: KMail

People: Ingo KlockerWaldo Bastian

Ingo Klocker sent the following message:

As you might have noticed the behavior of KMail when using Reply has changed since KDE 3.1. The current KMail tries to address the reply to the original sender of the message if Reply is used even for mailing-lists which set the Reply-to header. Of course this only works if KMail can figure out the mailing-list address and therefore can ignore it in case it's present in the Reply-to header. Anyway, what I'd like to know is whether this change is usability-wise a good change or not.

The current behavior is:
Reply ('r') -> reply to the original sender
Reply to Mailing-list ('l') -> reply to the mailing-list

The old behavior was:
Reply ('r') -> reply to Reply-to address if present, else to From; in case of Reply-to mangling mailing-list (seems to be the majority nowadays) this resulted in a reply to the mailing-list
Reply to Mailing-list ('l') -> reply to the mailing-list

With the old behavior it was impossible to send a private reply without using the mouse to right-click on the sender's address (which means that's actually an accessibility problem). This is the main reason why the new behavior was introduced.

Things which should be improved after KDE 3.2:
a) Rephrase "Reply" to "Reply to Sender"
b) Replace the two Reply buttons in the toolbar with a KToolBarPopupAction which contains all three Reply actions (-> one button less on the toolbar ;-) ) similar to the Forward button. The standard behavior of this button could be Reply to Mailing-list for mailing-list messages and Reply (to Sender) for normal messages.

The question now is whether it's necessary to revert the behavior to the old behavior until the new behavior is improved like above. The only valid reason for this is that probably many users always used Reply in case they wanted to reply to a mailing-list and that this worked for them up to now. A few people complained about this on kmail@kde.org and kde-pim@kde.org and there were also already 1 or 2 bugs reports about this. Of course, only those people complain that don't like the change. Those who like the new much more logical behavior don't speak up. Therefore I'd like to know what the usability team thinks about this.

Lots and lots of people asked for reverting the behaviour. Waldo Bastian even provided an example to show how "reply does not work anymore".

It was not clear whether the behaviour was reverted or not.

 

 

 

 

 

 

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.