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

KDE Traffic #31 For 20�Jan�2002

Editor: Aaron J. Seigo

By Aaron J. Seigo �and� Juergen Appel

Table Of Contents

Introduction

Welcome to KC KDE! It is bound to be a wild week as CVS is open for binary incompatible commits right through until Friday, January 25. Final changes, shifts and decisions are being made in preparation for that nervy moment when the project decides that the code in CVS HEAD is what will be KDE3. Since KDE3 will most likely have a shelf life of at least a couple of years this is no small decision.

Next to the bigger (and therefore more exciting) changes occuring in KDE's code base it is easy to overlook the small applications in KDE. One of the strengths of KDE is the abundance of programs that come with it, many of which are not very large or complex but often very useful. They can be found scattered throughout the CVS with especially heavy concentrations in the kdeutils, kdeaddons and kdetoys modules. Unfortunately, these small applications often end up somewhat neglected and lag in development. If you are looking for an easy way into KDE development, or are just burnt out on working on that megapatch you have been cooking up you may want to think about adopting one of these smaller applications if even just for a week or two. The users and maintainers of those apps will thank you and often the outstanding issues are fairly trivial.

We hope you enjoy this weeks summaries and Happy Hacking!

1. A period of new apps -episode I: Kalzium

7�Jan�2002 (1 post) Subject: "Kalzium"

Summary By Juergen Appel

Topics: KDE-Edu, New Application

As usual, the KDE-Edu-Devel members have been busy creating new applications. Though some are not yet ready for prime-time, Kalzium is. It is able to display the periodic system of elements, display the knowledge from f.x. 1756 only and much more. It even contains a quiz!

You can download Kalzium from its home page or from Appsy. For CVS use browse the POST_KDE_3_BRANCH and lookout for the module kdeedu/kalzium. The tarballs are for use with KDE 2.x, while the version in CVS requires a recent version of KDE 3.

The Author, Carsten Niehaus, reminds that Kalzium will not be part of the KDE-Edu release coming along with KDE 3.

2. Taking a look over the artists' shoulder

9�Jan�2002�-�11�Jan�2002 (14 posts) Archive Link: "Re: K-ARTIST:'art-devel' added added to KDE-CVS"

Summary By Juergen Appel

Topics: Look and Feel, Art, Icons, Animation

People: antialias,�Thorsten Rahn,�Torsten Rahn,�Chris Howells

antialias took the chance with the new cvs-module to coordinate the [K]artists' efforts:

I would like to know what tackat, qwertz, lenny and ather kde artist do right now, and that's not only because I am curious, but more because I don't want we all work on, for example, application icons while other icons stay untouched (not knowing about others work). I have this schedule right now:

Torsten Rahn aka Tackat replied to this:

Yesterday I added tear-off-borders to all 48x48-versions of ASCII-file-format-related icons. Looks a little bit more interesting. See screenshot below:

http://devel-home.kde.org/~tackat/status1.png

I plan to apply these to 32x32 and 64x64 as well.
Other items on my TODO-list:

Asked for an icon for koshell and kformula IIRC by Chris Howells, antialias came up with a nice set of icons. Take a look here. While Chris appreciated the submission,Torsten complained:

Well the issue I have with this is that it's always quite easy to create nice 64x64-icons the way you did. Once you actually create 48x48 -versions of these they start to look somewhat "overcrowded" and aren't very easy to "read".

The point I'm trying to make is that you used a very nice "KDE-ish" diamond for decorating the icon. This adds quite some "overhead" when it comes to fast recognition because of the higher number of icon-elements you have to recognize and distinguish.

On the other hand they look really nice. So .. maybe we should consider to add decoration-elements like you did for iconsizes larger than 48x48 only?

Didn't you want to take care of the 64x64-icons anyways :-) ?

antialias agreed to the concerns from Torsten explaining that he choose the diamond because current koshell icons have different shapes. He agreed that the diamond itself had too many elements pointing out that he had no time to clean the icons up and that they are just a basic design. For his future workantialias said:

I'll try first with 32x32 size, and choose just one element which is characteristic for Koshell applications. It's much easier with 48 & 64 icons, of course.

3. Word Wrapping in Dialogs

14�Jan�2002�-�17�Jan�2002 (28 posts) Archive Link: "Word-wrap in message boxes."

Summary By Aaron J. Seigo

Topics: UI

People: Waldo Bastian,�David Faure

Dialog boxes are such an integral part of the modern desktop environment that ensuring they are both usable and look good is quite important. Recently there have been long discussions about icons and text handling in dialogs for KDE3 and this week the topic of word wrapping was revisited. Waldo Bastian started the thread saying:

As of today, KMessageBox does not support word-wrap any longer. In KDE 2.2 KMessageBox didn't do word-wrap either, but some applications may have removed linefeeds from their messagebox texts already. They need to be re-added.

What's new for KDE 3.0 is that lines longer than 80 characters will be "squeezed". That means that a line like "This is a line longer than 80 chars." will become something like "This is a line lo...an 80 chars." (This example isn't really 80 chars wide of course)

When asked why word wrapping was removed Waldo explained:

Well basically our word-wrap isn't good enough. There are a few problems:

  1. We don't know how big the messagebox should be. That gets complicated by the fact that Qt is currently buggy and doesn't provide correct sizeHints in all situations. Theoretically we can pick any size above the minimum required size, and the text is supposed to flow into that, but chances are that this will look like shit. We also have a bunch of dialogs from 2.2 times that still have manual line-breaks and those are really ugly because it can happen that they automatically break one-word before the manual break. On the other hand if we use manual line-breaks we can size the dialog to fit the contents (see also 2) and whoever wrote the text can fidle with the line-breaks to make it a nice dialog that is well-balanced.
  2. We sometimes have data that exceeds reasonable width, e.g. think of a 200 character-long URL. We need to truncate that because otherwise we can end up with a dialog twice as wide as your screen, but that is rather hard with automatic word-breaks and it is very likely that the result will again look like shit due to single words ending up on a line of their own.

Discussion continued with most developers looking for a better word wrapping solution rather than simply abandoning the concept altogether. Eventually David Faure stepped up and said, "I volunteer to implement "squeezing single words (e.g. URLs) if longer than the max size for the dialog" in KWordWrap (as well as a mode for "only word-wrap at spaces" - it currently wraps at any punctuation sign, since this is necessary for desktop icons." Shortly thereafter Waldo said, "I seem to have found a reasonable algorithm to determine the size of a messagebox. It will prefer a size larger than the minimum required size but smaller than 1/3rd of the screen width. If the minimum required size is larger than 1/3rd of the screen width it will use that instead but it will never make the dialog wider than 2/3rd's of the screen. This is still based on Qt's WordBreak routines. It might be possible to squeeze words that don't fit into 2/3rd of the screen, but it will not be possible to provide a tooltip for that word only. That is, the tooltip will be active for the entire text and I guess should either contain the non-squeezed word or the total non-squeezed text."

A flurry of manual linebreak removal activity occurred in CVS and the discussion completed with everyone apparently happy.

4. KDE LDAP Administration Tool

16�Jan�2002 (5 posts) Archive Link: "[Kde-pim] NEW RELEASE: KDE Directory Administrator v0.2"

Summary By Aaron J. Seigo

Topics: KDE PIM, Filters

People: Patrick Patterson

The KDE PIM project has taken on new life in the post KDE2 time period. This activity isn't exclusive to just the core PIM applications but also third party development. One example is KDirAdm, which had its second release announced by Patrick Patterson:

KDirAdm is a LDAP Directory management tool written for the KDE Desktop Environment version 2 or later. It aims to provide all of the functionality of most commercial directory management tools, including:

Release Information: This release adds preliminary LDIF Import support, as well as the ability to modify user entries in the directory. If you run into problems with the LDIF import, PLEASE send us a bug report... it imports our test files correctly, but LDIF is such an ugly file format, that we probably didn't think of every possible combination to try. Shadow password support is still missing as well, although this will be in the next release. This release should be considered stable at this point, although it still lacks some functionality.

Current Features supported by KDirAdm:

The homepage for KDirAdm is at: http://www.carillonis.com/kdiradm where both source and Debian packages may be obtained.

Comments, suggestions, wishlist items and patches may be sent to the project co-ordinator at : ppatterson@carillonis.com

5. What Should Be Done in 3.0? What Should Be Left for 3.1?

16�Jan�2002�-�17�Jan�2002 (62 posts) Archive Link: "RELEASE DUDE: Re: Support for animated icons (on mouseover)"

Summary By Aaron J. Seigo

Topics: Release Schedule, KDE 3, Animation

People: Dirk Mueller

While discussing the icon animation patch, a discussion broke out regarding what sorts of features, fixes and improvements should be earmarked for the first release of KDE3 and which should be put on hold for KDE 3.1. Some features that have been completed (or are about to be completed) have been scheduled for 3.1 in the name of getting KDE3 out the door and others have not. To clarify how these decisions are made Dirk Mueller, the KDE3 release maintainer, wrote:

FAQ, see: http://developer.kde.org/development-versions/kde-3.0-release-plan.html

In short:

Now I didn't define "reviewal", and it doesn't mean "depends on what the release dude says", especially as I don't feel capable of deciding myself about some of the questions I get asked (i.e. because I don't know that specific code).

Instead I'd like to suggest the following rules / procedure, which also worked well in the past:

So its in short the "commits require reviewal" rule. Of course this outline is open for comments in case you think I've missed here something important. Don't consider this completely hardcoded and strict - i.e. I would say the maintainer's vote counts a bit more than those that are otherwise not working on the affected code. This is not a formal procedure - I prefer discussing and finding an agreement over any formalism. We should have better things to do than bending rules.

However, as a little reminder I want to append my usual rant about the schedule: Remember, we're very late in the release schedule, and for various reasons I actually do not want to delay it significantly anymore. So whatever you might think of _now_ that urgently _has_ to be in 3.0, please think twice about it first. 3.0 is not the end of the world, and IMHO it is preferable to ship something stable/bugfree over something that has the latest gimmick.

The _focus_ should be to get the API in a sane state and having things _easily_ _extensible_ for possible useful later changes and additions. And in case you're feeling bored now that you cannot work on the latest feature idea you're dreaming of for the whole last month already, think about taking a small look at the bugs database. Especially before you add a POST_3_0_BRANCH :-)

Thanks go out to Dirk for managing the KDE3 development and release process in an open and efficient manner.

6. Eye Candy Extraordinaire: Animated Icons

16�Jan�2002�-�18�Jan�2002 (62 posts) Archive Link: "Support for animated icons (on mouseover)"

Summary By Aaron J. Seigo

Topics: Look and Feel, Icons, Art, Animation

People: David Faure

Those using the pre-KDE3 code base have probably noticed the extended file information popups that appear when the mouse hovers over a file icon in Konqueror. The effect not only looks very nice but it is also quite useful. Of course, not all eye candy is usefull, sometimes it is purely for show. This week one such pure eye candy feature was coded, announced, discussed and finally added: animated icons. David Faure announced the patch saying:

The two patches attached provide support for animations on mouseover, as requested by our beloved artist (aka tackat ;) The main question is: given the current feature freeze, is it ok to commit this nonetheless ?

Details: The patch for am_edit makes it possible to install the mng already present in kdelibs/pics/hicolor. When the mouse goes over an icon (in konq/kdesktop), KIconLoader locates an mng with the same name as the icon (currently only folder.mng exists), then a QMovie is created to play it - each frame of the MNG is set as the QIconViewItem pixmap, quite simple.

The memory overhead is one pointer per icon (the movie, 0L most of the time), and the filename for the icon in a QString (e.g. "folder"). The patch moves m_size from KFileIVI to KIconViewItem -> no change for most iconviews, however this makes the patch BIC.

The thread meandered all over the KDE landscape from kicker to kpersonalizer as various developers offered their opinions on inclusion of the animated icons patch. Developers were urged to try it before balking, and many who did returned in favor of the feature. Bugs were found and squashed, memory usage was improved and various clean ups in the surrounding code ensued. In the end the patch was committed to KDE CVS. The feature is, of course, configurable.

7. How to Get Your Art Into CVS

20�Jan�2002 (3 posts) Archive Link: "K-ARTIST:FAQ:"

Summary By Juergen Appel

Topics: Meeting, IRC, Art

People: Torsten Rahn

Torsten Rahn has written a small HOWTO for artists interested in contributing their talent to KDE and make their names live forever:

If you want your stuff to be included with KDE send it to one of the artists who already do have a CVS-account (or to icons@kde.org). If your work is excellent and/or you are contributing on a regular basis you'll get a CVS-account.

If you get a CVS-account please also put your development-stuff (i.e. psd-files, xcf-files etc) into CVS (module: art-devel). This is how open source works and that's also the magic which will help our artwork to improve even faster!

Any major changes should first be discussed on the mailinglist kde-artists@kde.org. In addition you are always invited to chat with us on irc.kde.org #kde-artists.

Artwork which is meant for the inclusion into KDE in general MUST have to be free of copyright-issues. Always use your own artwork only (or artwork which belongs to the kde-project already!). Create your artwork from scratch and DO NOT use any clipart or stuff from other projects.

Icons which are meant for the inclusion into the default-icontheme:

Torsten suggested that meetings should be held on IRC Mondays 21:00 UT (GMT), it was agreed. So connect with your favorite irc-client to irc.kde.org and join #kde-artists.

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.