KDE Traffic #74 For 22 Jan 2004 By Henrique Pinto Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Threads Covered 1. 12 Jan 2004 - 14 Jan 2004 (9 Translations for KDE 3.2 posts) [kde-i18n-doc] 2. 1 Jan 2004 - 10 Jan 2004 (15 KOffice's Release Coordination posts) [koffice-devel] 3. 4 Jan 2004 - 5 Jan 2004 (8 New developers for KOffice posts) [koffice-devel] 4. 8 Jan 2004 - 20 Jan 2004 (38 KDE-Edu Icons [kde-edu] posts) 5. 7 Jan 2004 - 12 Jan 2004 (10 KControl [kde-usability] posts) Introduction Hi! This is KDE Traffic, issue #74. Due to personal issues, I was not able to work on KDE Traffic in the last three weeks, so there's much to cover. Instead of making a giant issue, I'm breaking the interesting topics in two issues (#74 and #75). Hope you like it! I'm not able to cover all KDE mailinglists. Especially missing are the Quanta and Kopete ones. If you think you can help, covering any KDE mailinglist, please contact me (mailto:henrique.pinto@kdemail.net) . Right now, the only mailinglists being covered are kde, kde-devel, kde-core-devel, kde-edu, kde-extra-gear, kde-pim, kde-promo, kde-usability, kfm-devel, kmail-devel, koffice-devel, kdepim-users and kde-i18n-doc. 1. Translations for KDE 3.2 [kde-i18n-doc] 12 Jan 2004 - 14 Jan 2004 (9 posts) Archive Link: "kde 3.2 language list" Topics: i18n, KDE 3.2 People: Piotr Szymanski Piotr Szymanski announced the list of translations that will be included in the 3.2 release with the following message: Hi, Dirk asked me to send it in advance, if any teams plan to do last minute commits and are not included in the list please reply to this thread. Thresholds: 75 % kdebase, dekstop_kdelibsm dekstop_kde-i18n 90% kdelibs.po If a language met the kdelibs criteria and didnt meet the other ones by less than 5% or it met all of the criteria except kdebase less than 10% than i included it with an *. az bg bs ca cs cy da de el en_GB es et eu* fa fi fr gl he hi** (it doesn't meet kdebase by 40%, but the maintainer said it'll meet the threshold by the freeze time) hu it nb nl nn pl pt pt_BR ro ru** (doesnt meet kdelibs but meets all the rest) sk sl sr sv ta tr uk uz* zh_CN zh_TW* Total: 48 incl. 3 * and 2 ** Not sure about including the following ones, they were in betas, but dont meet kdelibs and kdebase tresholds, but meet the desktop*: ja lt mn ms nso se tg (only 17% kdebase, but other quite high) ven xh zu Total: 10 2. KOffice's Release Coordination [koffice-devel] 1 Jan 2004 - 10 Jan 2004 (15 posts) Archive Link: "KOffice: The only thing worse than failure is the fear of trying something new" Topics: KOffice, Release Schedule People: Stefan Carl, David Faure, John Layt, Matthias Kalle Dalheimer, Lukas Tinkl, Nicolas Goutte, Zoltan Bartko, Werner Trobin, Nicolas Go, Thomas Zander Bashing release coordinators seems to be fashion nowadays. The following message was sent to the KOffice-devel mailinglist: To All KOffice Developers, We, the undersigned, believe that KOffice has failed to provide a compelling desktop office suite for KDE users. Furthermore, we believe that this can be attributed to Lukas Tinkl's inability to lead the KOffice development team. The collapse of the KOffice 1.3 release schedule and KDE-Debian's refusal of KOffice has clearly demonstrated the need for a new beginning. We believe that the failure of KOffice can be attributed to Lukas Tinkl's lack of interpersonal skills and indecisiveness. We wish to bring forth the plight of the Czech translator, where Lukas Tinkl failed to recognize his talents and contributions to KDE. Therefore, we ask Lukas Tinkl to show reason, within 48 hours, why he should not be removed from his current capacity as maintainer/release coordinator for KOffice. Should he fail to do so, we propose that David Faure be reinstated as maintainer of KOffice in light of his leadership and organizational talents, and his previous success in this position. We ask that KlavadalensdatkonsultAB to support David Faure in this endeavour. We also ask all developers who believe that David Faure would be a superior maintainer to Lukas Tinkl, to sign this petition. If, however, should you decide that Lukas Tinkl is better suited to this position, then please ignore this message and we apologise for your time. Respectfully, 1. Stefan Carl 2. Azuya Hunt 3. Chief Nelson Udu Needless to say, the KOffice developers supported Lukas Tinkl. David Faure stated that he "*totally* supports everything Lukas has done in relation to KOffice -- and he has consulted me and the other developers for most of the decisions, so this isn't surprising -- and he *has* done a much better job than I would have done with this release." John Layt advised people not to take that message seriously, "given that name #3 is actually from a notorious Nigerian Scam e-mail (just google it), and #2 sounds familiar from somewhere equally as dodgy..." Matthias Kalle Dalheimer also replied: Stefan, you have put forth quite substantial complaints about Lukas, but not substantiated them with any justification or explanation. It is against Klar?lvdalens Datakonsult AB's policy to influence internal organizational decisions of the KDE project, but personally, as a KDE developer, and the current President of KDE e.V., I am of course interested in helping to resolve any potential problems. In order to enable me to consider taking action, I will need you to: * give concrete examples about why you think Lukas is not suitable of leading the KOffice project, preferably including excerpts of email or other communication (if those excerpts have not been published to a public mailing list by the author, it would be inappropriate to do it now, please send those in private mail directly to me) * describe your and your co-signers' personal relation to the KDE project. Since you do not complain about technical issues like software quality or the like, but rather about organizational issues, I do assume that you are contributing to KDE in some way already, as the internal organization of the KDE project is only the business of the KDE contributors (developers, translators, artists, etc.) themselves. I already apologize in advance for not recognizing you, the project has simply grown too large for me to know all contributors. Please also include your co-signers' email addresses so that I can include them in further communication. However, if you are not able to provide these kinds of evidence to substantiate your claims, a public apology from your side to Lukas and the other KOffice developers would be in order. Lukas also took some time to comment on the message: Should I really comment on this crap from people I've never heard of before and who did nothing for KDE? There's nothing like a collapse, we just lack people and we were fixing bugs - hence the delays. But I'm sure you all know that... [...] Is there anything to add? I surely welcome the KDAB supporting David and if anybody raises his/her hands (from the real koffice developers), I'll just step back. Thomas Zander, Nicolas Goutte, Shaheed and Giovanni Venturi also posted, all of them showing support for Luk??. Nicolas' message was especially interesting, where he pointed out that KOffice really has/had problems, but none of them are due to Luk??. Nicolas also commented on the part of the original message where the poster gave Tinkl 48 hours to show why he should be the release dude: "That is totally absurd!" . Regarding all these posts, Zoltan Bartko commented: "I envy you, developers of KOffice, for you have the time to occupy your mind with things mentioned in this message thread." Instead of apologizing, however, Stephan Carl provided yet more unproven claims against Tinkl. In response to the new message, Werner Trobin posted: Please stop attacking Lukas Tinkl due to some personal issues you apparently have with him. Lukas is our release dude and invests lots of time in "boring" stuff like creating releases, struggling to get the translations together, and motivate kde-pr people to write announcements. He's accepted by all KOffice developers and this isn't going to change any time soon. Hopefully that was the end of the thread. 3. New developers for KOffice [koffice-devel] 4 Jan 2004 - 5 Jan 2004 (8 posts) Archive Link: "Do you need two more helping hands?" Topics: KOffice People: Jens B?ckman, Raphael Langerhorst, Clifford M. Roche Instead of bashing the release coordinator, Jens B?ckman posted to offer help: Hi! I've been reading the KDE traffic mailings for a while now, and see that there is always a note about the lack of developers almost every time KOffice is mentioned. After using KDE 3.1 as my primary desktop at work for a year and running various Linux distributions from 1997, I decided that it was time to take action. A little something about myself and my skills... I have been programming for thirteen years now, which is practically half of my life. Started with Basic, moved on to C and later on Assembler. Learned C++, Java and OO techniques in 1997 as I got accepted as a software engineer in Mid Sweden University. Graduated in 2000, and was hired for embedded programming immediately. Unfortunately, I'm currently a novice at Qt, and know nothing about the structure of either KDE or KOffice. Nothing that a week or two of reading documentation and source code won't remedy. So - do you need my help, and which part of KOffice should I focus on? Jens' post seemed to motivate more people to do the same thing. Shortly after Jens, Raphael Langerhorst also showed his wish to help: I'm also reading the list since mid november now and I really really wish to give you a hand (or two). At the moment I'm just involved in too much to be of much use and I would also have to get the insides known of KOffice, so I want to have time for it. KOffice is - as far as I found out - really a great project and I think it basically has a lot of potential, being able to base on a solid base like KDE. Clifford M. Roche also offered help: Hey, I am a new developer that just joined KOffice, I really like the potential it has over OpenOffice and would like to see more functionality from it in its upcoming releases, since I am in a position that a bit of work on an Opensource project would look good on me, so I figured that I would join and help out a bit, whatever I can. I have also developed for Win32 based platforms for a really long time and only recently started to make the jump to X-Windows, so I figure that this will help out a lot. I hope more and more people show interest in helping the KOffice project... 4. KDE-Edu Icons [kde-edu] 8 Jan 2004 - 20 Jan 2004 (38 posts) Archive Link: "KDE-Edu icons - Artist needed" Topics: KDE-Edu, Art People: Anne-Marie Mahfouf, David Vignoni, Eva Brucherseifer While porting KDE-Edu to MacOS X, it was noticed that the biggest size of icons for the applications in that KDE module was 32x32 and, as such, those icons didn't look well on bigger sizes (MacOS X seems to use 128x128 icons in the dock). So, the KDE-Edu developers asked for help. Anne-Marie Mahfouf summarized what was needed in the following message: After my previous enquiry to kde-artist, I made a list of existing and missing icons for each edu application (list is attached). Summary: all applications except KStars need a svg rendering for the application icons (it is not clear at the moment where the svg file should be committed in cvs). From the svg file, the png icons in all format will be easily derived (with maybe a bit of work for 16x16). So we need to start working on that, it would be nice to have it done before 3.2 is out. Any volunteer is welcome, even if you have only time for one icon! Eva Brucherseifer suggested writing to kde-look asking for help. The idea was well received and an item was added to the news section of kde-look.org (http:/ /www.kde-look.org) . David Vignoni offered help: Hi, my name is David Vignoni, I've done some artwork for kde-look (nuvola icons, lush icons and melody) and other works I'll show in my future website. I can do that work you need, can you please send me the old icons you need to been redone please? I know I can found them but I'm sure I'll not find some. Anne-Marie Mahfouf sent him the old icons, and he quickly sent new versions of those icons. Meanwhile, Everaldo Coelho (author of the CrystalSVG icon theme) posted to kde-look stating that he will work on icons for the KDE-Edu application and that they'll be included in the next Crystal version. David expressed his concerns: I've read at kde-look that everaldo will already include icons in the next release of crystal, so maybe you don't need these icons anymore... in any case I'll include them in my themes. Anne-Marie replied: all icons? well, first we need to see if this is real and maybe then have a choice. At the moment, it has not been made clear that all icons will be done by Everaldo and it's still the app's author that has to get his/her icon done. The svg sources have not been made available for the existing crystal icons so I prefer not count on an uncertain future but rely on David's nice work. 5. KControl [kde-usability] 7 Jan 2004 - 12 Jan 2004 (10 posts) Archive Link: "kcontrol redux, ad infinitum " Topics: KControl People: Aaron J. Seigo Lots and lots of discussion regarding KControl happened in the kde-usability list. Tired of all that discussion going on again and again (KControl is kde-usability's favorite subject), Aaron J. Seigo posted: hi all... i've stayed pretty much completely out of the kcontrol discussion that's been ongoing because i'm tired of discussing it for the Nth time. =) i and others have been around this tree many times already. most of the discussions can be found in the archives for this list, but here's a synopsis of my personal conclusions to date: the key is the navigation and feedback interface not the panels, the names of the panels, the hierarchy they are in, the order of tabs on the left or any other part of kcontrol. those items are all things that can and should be addressed only after the main interface has been properly refitted. some details: * using separate windows is a compromise position. most users don't deal with multiple windows well and there are few if any panels that require other panels open at the same time to be useful, so this should be avoided if at all possible. * simple file browser like icon interfaces suck: you can't tell where you need to go if you organize things into "folders", and if you don't organize them into a hierarchy you end up with a morass of panels. * only so many panels can be eliminated, and for better or worse there's no way to stop 3rd parties from adding to the panels. * there are some clear and simple distinctions between large groups of the panels: hardware, administration tasks and everything else * the relationships between panels are multidimensional. no amount of hierarchy reshuffling or renaming will make that any different. the interface to the panels should therefore reflect this reality as opposed to try and work around it. * the search should be integrated into the top level of the kcontrol interface and should be able to display results in the same place that the panels usually appear. think google search in your web browser meets kcontrol. the search index parameters need to be extended as well to include keyword ranking and relationships to other panels. * a metadata view should probably be provided alongside each panel that shows at a minimum short help (50 words or less), links to extended help and related panels, and perhaps a shorthand system for simple navigation * the MacOS X control panel with top level groups and panels provides some interesting lessons we can learn from * metapanels are an interesting avenue to explore. the new theme manager metapanel being worked on is a good example of this. From Aaron's post, it was clear that the main issue with KControl is its navigational method. Aaron's conclusions were agreed upon, but no one posted ideas on how to improve the situation yet. 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.