Add your blog

If you are a KDE contributor you can have your blog on Planet KDE. Blog content should be mostly KDE themed, English language and not liable to offend. If you have a general blog you may want to set up a tag and subscribe the feed for that tag only to Planet KDE.

To have your blog added file a bug in Bugzilla listing your name, svn account (if you have one), IRC nick (if you have one), RSS or Atom feed and what you do in KDE. Attach a photo of your face for hackergotchi.

Alternatively, Planet KDE is kept in KDE's SVN. If you have an account you can add or edit your own feed:

  • svn checkout svn+ssh://@svn.kde.org/home/kde/trunk/www/sites/planet/
  • Put your hackergotchi in website/hackergotchi/. A hackergotchi should be a photo of your face smaller than 80x80 pixels with a transparent background. svn add the file.
  • At the end of the planetkde/config file add your details (the name in brackets is your IRC nick):
  • feed 45m http://path.to/my/feed.rss define_name Konqi Konqueror (konqi) define_face hackergotchi/konqi.png define_facewidth 80 define_faceheight 80
  • svn commit

If you want to add a Twitter microblog to the Microblogging sidebar add define_microblog true and follow your name with [twitter]. Currently only Twitter is known to work, please contact Jonathan Riddell before adding non-Twitter microblogs to check it works.

Planet KDE Guidelines

Planet KDE is one of the public faces of the KDE project and is read by millions of users and potential contributors. The content aggregated at Planet KDE is the opinions of its authors, but the sum of that content gives an impression of the project. Please keep in mind the following guidelines for your blog content and read the KDE Code of Conduct. The KDE project reserves the right to remove an inappropriate blog from the Planet. If that happens multiple times, the Community Working Group can be asked to consider what needs to happen to get your blog aggregated again.

If you are unsure or have queries about what is appropriate contact the KDE Community Working Group.

Blogs should be KDE themed

The majority of content in your blog should be about KDE and your work on KDE. Blog posts about personal subjects are also encouraged since Planet KDE is a chance to learn more about the developers behind KDE. However blog feeds should not be entirely personal, if in doubt set up a tag for Planet KDE and subscribe the feed from that tag so you can control what gets posted.

Posts should be constructive

Posts can be positive and promote KDE, they can be constructive and lay out issues which need to be addressed, but blog feeds should not contain useless, destructive and negative material. Constructive criticism is welcome and the occasional rant is understandable, but a feed where every post is critical and negative is unsuitable. This helps to keep KDE overall a happy project.

You must be a KDE contributor

Only have your blog on Planet KDE if you actively contribute to KDE, for example through code, user support, documentation etc.

It must be a personal blog

Planet KDE is a collection of blogs from KDE contributors. It is not indended for project news feeds.

Do not inflame

KDE covers a wide variety of people and cultures. Profanities, prejudice, lewd comments and content likely to offend are to be avoided. Do not make personal attacks or attacks against other projects on your blog.

For further guidance on good practice see the KDE Code of Conduct.

People Aggregated

FeedRSS
A. L. Spehr (blauzahl) feed
A. L. Spehr (blauzahl) [identi.ca] feed
Aaron Reichman (areichman) feed
Aaron Seigo (aseigo) feed
Aaron Seigo [identi.ca] feed
Abhishek Patil (_abhishek) feed
Achim Bohnet (ach) feed
Adam Celarek (adamce) feed
Adam Kidder (thekidder) feed
Adam Pigg feed
Adam Rakowski (foo-script/efes) feed
Adam Treat (manyoso) feed
Adenilson Cavalcanti (Savago) feed
Aditya Bhatt (adityab) feed
Adriaan de Groot (adridg) feed
Adrien Facelina feed
Agustin Benito Bethencourt feed
Agustin Benito Bethencourt [twitter] feed
Ahmed Ghonim feed
Aike Sommer feed
Akarsh Simha (kstar) feed
Akarsh Simha [twitter] feed
Alan Alvarez (clsk) feed
Albert Astals Cid (TSDgeos) feed
Aleix Pol (apol) feed
Alejandro Wainzinger (xevix) feed
Alessandro Diaferia (alediaferia) feed
Alessandro Sivieri (Siv) feed
Alex Fiestas (afiestas) feed
Alex Fiestas [identi.ca] feed
Alex Merry feed
Alex Raymond (alexraymond) feed
Alexander Dymo (adymo) feed
Alexander Neundorf feed
Alexander Rieder (arieder) feed
Alexandr Goncearenco feed
Alexandra Leisse (troubalex) feed
Alexandra Leisse [twitter] feed
Alexis Menard (darktears) feed
Alexis Menard (Qt Development Frameworks) feed
Allan Sandfeld Jensen (carewolf) feed
Allen Winter feed
Alvaro Soliverez (Hei_Ku) feed
Ana Cecilia Martins (annieC) feed
Ana Guerrero (ana) feed
Andi Clemens (aclemens) feed
Andras Mantia feed
Andre Moreira Magalhaes (andrunko) feed
Andrea Diamantini (adjam) feed
Andrea Scarpino (bash) feed
Andreas Aardal Hanssen (bibr) feed
Andreas Demmer (ademmer) feed
Andreas Hartmetz feed
Andreas Huggel (ahuggel) feed
Andreas Marschke feed
Andreas Pakulat feed
Andreas Ramm (psychobrain) feed
Andreas Schneider (gladiac) feed
Andrew Coles (coles) feed
Andrew Lake (Jamboarder) feed
Andrew Manson ( mansona aka real_ate ) feed
Andrew Stromme (astromme) feed
Angelo Naselli (anaselli) feed
Anne Wilson (annew) feed
Anne-Marie Mahfouf (annma) feed
Anselmo Lacerda S. de Melo (anselmolsm) feed
Antonio Aloisio feed
Antonio Larrosa Jimenez (antlarr) feed
Aracele Torres (araceletorres) feed
Arindam Ghosh feed
Ariya Hidayat feed
Arjen Hiemstra (ahiemstra) feed
Arnaud Dupuis (Arno[Slack]) feed
Arnd Baecker (abaecker) feed
Arno Rehn (pumphaus) feed
Artur Souza (MoRpHeUz) feed
Artur Souza (MoRpHeUz) [identi.ca] feed
Ashley Winters feed
Aurelien Gateau feed
Bart Cerneels (Stecchino) feed
Bart Cerneels (Stecchino) [identi.ca] feed
Bart Coppens (BCoppens) feed
Bartosz Wadolowski feed
Bastian Holst (bholst) feed
Ben Klopfenstein (benklop) feed
Ben Martin (monkeyiq) feed
Benjamin Meyer (icefox) feed
Benjamin Port (ben2367) feed
Benjamin Reed (RangerRick) feed
Bernd Buschinski (buscher) feed
Bertjan Broeksema feed
Björn Balazs feed
Björn Ruberg (ruberg) feed
Bjørn Erik Nilsen (bnilsen) feed
Boudewijn Rempt (boud) feed
Boudewijn Rempt's Krita blog feed
Brad Hards (bradh) feed
Brad Hughes feed
Bruno Abinader (abinader) feed
Camila Ayres (camilasan) feed
Carlos Leonhard Woelz (cwoelz) feed
Carlos Licea feed
Carsten Niehaus (carsten) feed
Carsten Pfeiffer (gis) feed
Casey Link (ramblurr) feed
Casey Link [twitter] feed
Casper Boemann feed
Casper van Donderen (cvandonderen) feed
Celeste Lyn Paul (seele) feed
Celeste Lyn Paul [twitter] feed
Chani Armitage (Chani) feed
Chani Armitage [twitter] feed
Charles huet (Packadal) feed
Chris Lee (clee) feed
Christian Ehrlicher feed
Christian Loose feed
Christian Muehlhaeuser (muesli) feed
Christian Weilbach (whilo) feed
Christoph Cullmann (cullmann) feed
Christoph Feck (kdepepo) feed
Christophe Olinger (binarylooks) feed
Cies Breijs (cies) feed
Clarence Dang feed
Colin Guthrie (coling) feed
Constantin Berzan (exit) feed
Cornelius Schumacher feed
Cornelius Schumacher [twitter] feed
Cristian Tibirna (Inorog) feed
Cyril Oblikov (munknex) feed
Cyrille Berger feed
Cyrille Berger feed
Dan Jensen (leinir) feed
Daniel Jones feed
Daniel Laidig (dani_l) feed
Daniel Meltzer (hydrogen) feed
Daniel Molkentin (danimo) feed
Daniel Molkentin [Qt Labs] (danimo) feed
Daniel Molkentin [twitter] feed
Daniel Nicoletti (dantti) feed
Daniel Winter (DanielW) feed
Daniele E. Domenichelli (drdanz) feed
Daniele E. Domenichelli [identi.ca] feed
Danny Kukawka feed
Dario Andres Rodriguez (Dario_Andres) feed
Dario Freddi (drf__) feed
Dario Freddi [identi.ca] feed
Dario Massarin feed
David Faure (dfaure) feed
David Faure [identi.ca] feed
David Hubner (hubner) feed
David Miller feed
David Nolden feed
David Vignoni (davigno) feed
Davide Bettio (WindowsUninstall) feed
Declan McGrath (declanmg) feed
Dennis Nienhüser (Earthwings) feed
Derek Kite (dkite) feed
Detlev Casanova (Cazou) feed
Diana Tiriplica (dianat) feed
Diederik van der Boor feed
Diego Casella ([Po]lentino) feed
Diego Iastrubni feed
Dimitri Popov feed
Dinesh (saidinesh5) feed
Dion Moult (Moult) feed
Dirk Mueller feed
Dmitry Ivanov (vonami) feed
Dmitry Kazakov (dmitryK) feed
Dmitry Suzdalev (dimsuz) feed
Dominik Haumann feed
Dominik Seichter feed
Duncan Mac-Vicar (duncanmv) feed
Eduardo Robles Elvira (Edulix) feed
Edward Toroshchin (hades) feed
Egon Willighagen feed
Ellen Reitmayr (el) feed
Elvis Stansvik (estan) feed
Emil Sedgh (emilsedgh) feed
Enrico Ros feed
Erlend Hamberg feed
Esben Mose Hansen (esben) feed
Espen Riskedal feed
Eva Brucherseifer feed
Evgeniy Ivanov (powerfox/pfx) feed
Fabio A. Locati (flocati) feed
Fabrice Mous (fab) feed
Fabrizio Montesi (fmontesi) feed
Fathi Boudra (fabo) feed
Felix Lemke (HobbyBlobby) feed
Filipe Saraiva (filipesaraiva) feed
Flavio Castelli feed
Florian Graessle (holehan) feed
Francis Giannaros (apokryphos) feed
Frank Karlitschek (karli) feed
Frank Osterfeld (fosterfeld) feed
Frank Osterfeld [identi.ca] feed
Frans Englich (FransE) feed
Franz Keferboeck feed
Fred Emmott (fred87) feed
Frederic Coiffier (fcoiffier) feed
Frederik Gladhorn (fregl) feed
Frederik Gladhorn (fregl) feed
Frederik Gladhorn [identi.ca] feed
Frederik Schwarzer (icwiener) feed
Fredrik Höglund feed
Fredy Yanardi feed
Frerich Raabe feed
Friedrich Kossebau (frinring) feed
Gabriel Voicu (gvoicu) feed
Gary Greene (greeneg) feed
Gary Steinert (gsteinert) feed
Gaurav Gupta (gg) feed
George Goldberg (grundleborg) feed
George Goldberg [twitter] feed
George Kiagiadakis (gkiagia) feed
George Wright (gw280) feed
Gerhard Kulzer (gkulzer) feed
Germain Garand feed
Gianluca Urgese (gurgese) feed
Gilles Caulier (cgilles) feed
Girish Ramakrishnan feed
Girish Ramakrishnan feed
Gokmen Goksel (gokmen) feed
Gopala Krishna feed
Gran Canaria Desktop Summit [twitter] feed
Greg Meyer (oggb4mp3) feed
Gregor Iaskievitch feed
Gregory Haynes feed
Guillaume DE BURE (gdebure) feed
Guillermo Amaral (gamaral) feed
gamaral [twitter] feed
Gustavo Boiko feed
Hamish Rodda (blackarrow) feed
Hanna Skott (hannaskott) feed
Hans Chen (Mogger) feed
Harald Fernengel feed
Harald Hvaal (metellius) feed
Harald Sitter (apachelogger) feed
Harald Sitter [identi.ca] feed
Harri Porten feed
Harshit Jain (hjain) feed
Helio Castro (heliocastro) feed
Henri Bergius (bergie) feed
Henrique Pinto feed
Henry de Valence (hdevalence) feed
Holger Foerster (foerster) feed
Holger Freyther (zecke) feed
Hugo Pereira Da Costa feed
Ian Geiser (geiseri) feed
Ian Monroe (eean) feed
Ian Monroe [twitter] feed
Igor Trindade Oliveira feed
Inge Wallin (ingwa) feed
Ingo Malchow (neverendingo) feed
Ingomar Wesp (iwesp) feed
Isaac Clerencia feed
it-s feed
Ivan Čukić (ivan) feed
Ivan Čukić [identi.ca] feed
Jacob Rideout (rideout) feed
Jakob Petsovits (jpetso) feed
James Ots feed
Jan Hambrecht (jaham) feed
Jan Kundrat (jkt) feed
Jan Muehlig (janushead) feed
Janet Theobroma (theobroma) feed
Jarle Akselsen feed
Jarosław Staniek (jstaniek) feed
Jaroslav Řezník (jreznik) feed
Jason A. Donenfeld (zx2c4/jdonenfeld) feed
Jason Harris (LMCboy) feed
Jason Kasper (vanRijn) feed
Jason McDonald (Qt Development Frameworks) feed
Jean-Nicolas Artaud (morice-net) feed
Jeff Mitchell (jefferai) feed
Jens Muller (jmueller) feed
Jens-Michael Hoffmann (jmho) feed
Jeremias Epperlein feed
Jeremy Whiting (jpwhiting) feed
Jeremy Whiting [identi.ca] feed
Jesper K. Pedersen (blackie) feed
Jesper Thomschutz feed
Jesper Thomschutz [twitter] feed
Johan Thelin feed
Johann Ollivier Lapeyre feed
Johannes Bergmeier (joselb) feed
Johannes Wienke (languitar) feed
John Layt feed
John Ratke feed
John Tapsell (JohnFlux) feed
John-Paul Stanford (jp) feed
Jonathan Riddell (riddell) feed
Jonathan Riddell [twitter] feed
Jonathan Thomas (JontheEchidna) feed
Joon-Kyu Park feed
Jordi Polo (jordl) feed
Jorge Mata (mata) feed
Jos Poortvliet feed
Jos Poortvliet [twitter] feed
Jos van den Oever (vandenoever) feed
José Luis Vergara Toloza (Pentalis) feed
Josef Spillner feed
Joseph Wenninger feed
Julien Narboux (jnarboux) feed
Jure Repinc (JLP) feed
Jure Repinc [identi.ca] feed
Jussi Kekkonen (Tm_T) feed
Jussi Schultink (jussi01) feed
Justin Kirby (neomantra) feed
Justin Kirby [identi.ca] feed
Kashyap Puranik (kashthealien) feed
Kaushik Saurabh (roide) feed
Keith Rusler (comawhite) feed
Kenneth Wimer (kwwii) feed
Kent Hansen feed
Kevin Krammer feed
Kevin Ottens (ervin) feed
Kevin Whitaker (eyecreate) feed
Klaas Freitag (dragotin) feed
Koos Vriezen feed
kunal ghosh (kunalghosh) feed
Kurt Hindenburg feed
Kurt Pfeifle (pipitas) feed
Lamarque Souza (lamarque or lvsouza) feed
Lars Knoll feed
Laurent Espitallier (lespitallier) feed
Leo Franchi (lfranchi) feed
Leo Franchi [twitter] feed
Leonardo Sobral Cunha (lsobral) feed
Lim Yuen Hoe (moofang) feed
Loic Corbasson feed
Lorn Potter feed
Lubos Lunak (llunak) feed
Luca Beltrame (einar77) feed
Lucas Murray (lmurray) feed
Lucijan Busch (lucijan) feed
Luis Augusto Fretes Cuevas feed
Luiz Romário (luizromario) feed
Lukas Appelhans feed
Lukas Appelhans [twitter] feed
Lukas Kropatschek feed
Lukas Tinkl feed
Lukas Tvrdy (lukast) feed
Lydia Pintscher (Nightrose) feed
Lydia Pintscher [twitter] feed
Mahfuz062 feed
Maksim Orlovich (SadEagle) feed
Manfred Mislik (tictric) feed
Marc Cramdal feed
Marc Mutz feed
Marc Pegon (mpeg) feed
Marcel Wiesweg (mwiesweg) feed
Marco Gulino (RockMan) feed
Marco Martin (notmart) feed
Marco Martin [twitter] feed
Marco Mentasti (mentasti) feed
Marcus Hanwell (cryos) feed
Marijn Kruisselbrink feed
Mario Fux (unormal) feed
Marius Bugge Monsen (Qt Development Frameworks) feed
Mark Kretschmann (markey) feed
Mark Kretschmann [twitter] feed
Markus Slopianka (markuss) feed
Martijn Klingens feed
Martin Gräßlin feed
Martin Klapetek (mklapetek) feed
Martin Konold (Mortimer) feed
Martin Sandsmark (sandsmark) feed
Martin Sandsmark [twitter] feed
Martin Wilke (miwi) feed
Martyn Circus feed
Mathias Kraus (hias) feed
Mathieu Chouinard (chouimat) feed
Matt Broadstone feed
Matt Williams feed
Matthias Ettrich feed
Matthias Fuchs (mat69) feed
Matthias Kretz (Vir) feed
Matthias Kretz [identi.ca] feed
Mauricio Piacentini (piacentini) feed
Maurizio Monge feed
Mauro Iazzi (iazzi) feed
Max Howell (mxcl) feed
Mehrdad Momeny (mtux) feed
Mensur Zahirovic (Nookie) feed
Michał Małek (mmalek) feed
Michael Forney (tridactyla) feed
Michael Jansen feed
Michael Krog feed
Michael Leupold (lemma) feed
Michael Pyne (mpyne) feed
Miha Čančula (Noughmad) feed
Mike McQuaid (mikemcquaid) feed
Mike McQuaid [twitter] feed
Mikolaj Machowski (mikmach) feed
Milian Wolff (milianw) feed
Mirko Boehm (miroslav) feed
Morten Sørvig feed
Myriam Schweingruber (Mamarok) feed
Myriam Schweingruber [twitter] feed
Nadeem Hasan feed
Navindra Umanee feed
Nick Shaforostoff (shaforostoff) feed
Nicola Gigante (gigabytes) feed
Nicolas Lécureuil (neoclust) feed
Nicolas Lecureuil (nlecureuil) feed
Niels van Mourik (nielsvm) feed
Nikhil Marathe (nsm) feed
Niko Sams (nsams) feed
Nikolaj Hald Nielsen feed
Nikolaj Hald Nielsen [twitter] feed
Nikolas Zimmermann (WildFox) feed
Nuno Pinheiro (pinheiro) feed
Nuno Povoa (npovoa) feed
Oleksiy Protas (Landswellsong) feed
Olivier Goffart (Gof) feed
Orville Bennett (illogic-al) feed
Ozan Çağlayan (ozancaglayan) feed
Paolo Capriotti feed
Park Shinjo (peremen) feed
Patrick Aljord (patcito) feed
Patrick Spendrin (SaroEngels) feed
Pau Garcia i Quiles (pgquiles) feed
Paul Adams feed
Paul Pacheco (paulpach) feed
Paulo Rômulo (promulo) feed
Pedro Lopez-Cabanillas feed
Peter Grasch feed
Peter Grasch [identi.ca] feed
Peter Penz feed
Peter Schiffer (aceton) feed
Peter Simonsson (psn) feed
Petr Rockai (mornfall) feed
Petr Vanek feed
Petri Damstén feed
Philip Rodrigues (PhilRod) feed
Pierre Ducroquet feed
Pino Toscano (pinotree) feed
Piyush Verma feed
Pradeepto [twitter] feed
Pradeepto Bhattacharya feed
Prakash Mohan (praksh) feed
Rafał Miłecki (Zajec) feed
Rafael Fernández López (ereslibre) feed
Rainer Endres (physos) feed
Ramon Zarazua (_killerfox_) feed
Raphael Kubo da Costa (rakuco) feed
Raymond Wooninck (tittiatcoke) feed
Reinhold Kainhofer feed
Remi Villatel feed
Rex Dieter (rdieter) feed
Riccardo Iaconelli (ruphy) feed
Riccardo Iaconelli [twitter] feed
Richard Dale feed
Richard Johnson (nixternal) feed
Richard Johnson [twitter] feed
Richard Moore (richmoore2) feed
Risto Saukonpaa (fri13) feed
Rivo Laks feed
Rob Buis (rwlbuis) feed
Rob Scheepmaker (pinda) feed
Robert Knight feed
Robert Mathias Marmorstein (robertm) feed
Robert Riemann (saLOUt) feed
Roberto Raggi feed
Robin Burchell (w00t) feed
Robin Burchell [identi.ca] feed
Rohan Prabhu (thirtySeven) feed
Roland Wolters (liquidat) feed
Rolf Eike Beer (Dakon) feed
Romain Pokrzywka (kromain) feed
Ronny Yabar (ronnyml) feed
Roopesh Chander feed
Roozbeh Shafiee feed
Ryan Bitanga feed
Ryan Rix (PhrkOnLsh) feed
Sabine Emmy Eller feed
Sacha Schutz (DrIDK) feed
Sam Duff (Socceroos) feed
Samuel Rødal feed
Sander Koning feed
Sandro Andrade (sandroandrade) feed
Sascha Manns (saigkill) feed
Sascha Peilicke (saschpe) feed
Sascha Peilicke [twitter] feed
Sayak Banerjee (sayakb) feed
Sayak Banerjee [twitter] feed
Scott Collins feed
Scott Wheeler (wheels) feed
Seb Ruiz (sebr) feed
Seb Ruiz [twitter] feed
Sebastian Kügler (sebas) feed
Sebastian Kügler [twitter] feed
Sebastian Pipping (sping) feed
Sebastian Sauer (dipesh) feed
Sebastian Trueg feed
Sebastian Trueg (trueg) feed
Shantanu Tushar (shantanu) feed
Shashank Singh (ssingh) feed
Shashank Singh [twitter] feed
Shaun Reich (sreich) feed
Shawn Starr (spstarr) feed
Siddharth Sharma (h4xordood) feed
Siddharth Srivastava (akssps011) feed
Simon Edwards feed
Simon Esneault feed
Simon Hausmann (tronical) feed
Simon St James (SSJ_GZ) feed
Sjors Gielen (Sjors/sgielen) feed
Sri Ramadoss M (amachu) feed
Stefan Eilers feed
Stefan Majewsky (majewsky) feed
Stefan Teleman feed
Stephan Binner (Beineri) feed
Stephan Binner [twitter] feed
Stephan Kulow (coolo) feed
Stephanie Das Gupta (stephdg) feed
Stephen Kelly (steveire) feed
Stuart Jarvis feed
Sujith H (sujith_h) feed
Sune Vuorela (pusling) feed
Sven Burmeister (rabauke) feed
Sven Langkamp (slangkamp) feed
Téo Mrnjavac (Teo`) feed
Tejas Dinkar (gja) feed
Tejas Dinkar [twitter] feed
Theo Chatzimichos (tampakrap) feed
Thiago Macieira (thiago) feed
Thomas Abthorpe (tabthorpe) feed
Thomas Capricelli (orzel) feed
Thomas McGuire feed
Thomas McGuire [identi.ca] feed
Thomas Thym (ungethym) feed
Thomas Zander (ThomasZ) feed
Thomas Zander (ThomasZ) feed
Till Adam feed
Timo Hoenig feed
Tina Trillitzsch feed
Tobias Hunger feed
Tobias Koenig (tokoe) feed
Tobias Koenig (tokoe) feed
Tom Albers feed
Tom Albers [identi.ca] feed
Tomaz Canabrava (tomaz) feed
Tony Murray (murrant) feed
Tor Arne Vestbø feed
Torsten Rahn (tackat) feed
Trever Fischer (tdfischer) feed
Trever Fischer [identi.ca] feed
Troy Unrau feed
Urs Wolfer feed
Valerio Pilo (Amroth) feed
Valorie Zimmerman (valorie) feed
Vavelin Kevin (Kusa) feed
Victor Carbune (carbonix) feed
Vinicius Azevedo (stdcout) feed
Vishesh Handa (vhanda) feed
Vito Chiarella (vitochiarella) feed
Vitor Boschi (Klanticus) feed
Vlad Codrea feed
Vladimir Kuznetsov feed
Vladimir Prus feed
Volker Lanz (Torch) feed
Vyacheslav Tokarev (vtokarev) feed
Wade Olson feed
Wagner Reck (wiglot) feed
Waldo Bastian (zogje) feed
Wang Hoi (wkai) feed
Wendy Van Craen feed
Wesley Stessens feed
Will Stephenson feed
Will Stephenson [twitter] feed
William Viana (Liw-) feed
Witold Wysota feed
Xavier Vello (xvello) feed
Zack Rusin (zrusin) feed

Microblogging from KDE

August 01, 2010

Jos Poortvliet

Just started...

Hi all!

As of now I'm an employee of Novell. That means a couple of things.

First of all: awesomeness, working with all of you!

Second the boring stuff: I'll have to update linked-in and some other sites. And put a disclaimer on this site - my previous employer (the Dutch government) wasn't exactly involved in what I did for KDE... And I'll have to go through the administrative stuff in the company. Boy, do I look forward to that ;-)

Third, I should get started. I'll be flying to the US of A tomorrow to meet people at the Novell offices. So if you want me to tell them anything in particular, let me know! Remember, for now, it's my FirstNameLastName on gmail if you want to mail me.

Besides that, I will of course start doing things within and for openSUSE. After all, my job will basically have three sides (at least that's how I currently see it):


  • Help openSUSE archieve world domination (eg be a volunteer in openSUSE, evangalize to the outside world etc)

  • Work on the relationship between Novell and openSUSE (eg corporate communication, organizing events & stuff)

  • Spread and promote openSUSE within Novell



Now I might have this nice 'community manager' title, but as I said before, please note that that's just a Novell title. Nice towards the outside and for points 2 and 3, but within the community - don't expect me to change anything on my own... I'll just be another dude trying to help out. I'll take on things which I think are important (I'll obviously listen to suggestions) but I can't promise to solve every single problem there is. There are only 24 hours in a day and I need my beauty sleep!

But still, excitement is keeping me awake right now - I seriously look forward to this. There is interesting stuff going on, not the least of which are the strategy discussions going on. If you want to have a say in where openSUSE goes - get involved.

Rock on,

Jos

03:21, Sunday, 01 August UTC

Nikhil Marathe (nsm)

Whats up doc?

Pardon me for the excessively cliche title, I was short on time :P

Its been a week now since college began, and already I feel the
extreme busy-ness that occurs trying to squeeze every activity into 24
hours. The vacations were comparatively totally empty.

The UPnP collection support in Amarok is concluding pretty well. Today
I committed the fix that considerably shortens the amount of data
transfer required over the network for subsequent queries once the
local cache is relatively filled. With a relatively small share on
miniDLNA, I got near native performance, with the tracks being
populated as soon as I opened up a tree. The kioslave too has had some
additions that allow applications using it to bypass many of the
user-friendly features (required for browsing via Dolphin or
Konqueror) and get blazing fast results instead.

With another Amarok release coming up, I want to get some time to fix
bugs, but it has been hard to come by, even on a weekend.

My other pet KDE project has been Rekonq, more specifically Chrome
extension support. I can't remember the last time I blagged about it,
but just so it doesn't get buried as defunct project, let me give a
status update. Work is slow but not stalled. I have extension
installation working. I have figured out how to interface the C++ and
JS parts, although it is a bit hacky. The Chrome Tabs API is mostly
implemented, (localization and script injection and message passing
are not), including the captureVisibleTab() method. Now that I have
some experience, it should be much easier to implement the rest of the
APIs. I still have to figure out how to implement background pages
(most likely a WebTab not added to the UI), implement safe message
passing and so on. A nice UI to manage extensions would also be
required, and it would be great if others are interested in jumping in
to the project.
I would be glad to explain the architecture ( I have a IRC log lying
around, thanks to Rohan Garg :P )

I don't know about 1.0, but extension support will get there in the
end, so lets not remove my name from the Credits :)

Posted via email from nikhil's posterous

02:10, Sunday, 01 August UTC

Cyril Oblikov (munknex)

GSoC 2010: Mind Mapping in KOffice

Hi guys. I'm GSoC student Cyril Oblikov. And this is the first post about my project - Mind Mapping in KOffice. Mid-term evaluations deadline coming soon, and I'd like to describe what is done for this moment.

A key element of mind map is tree which layouts shapes with text. I decided tree may be usefull not only for mind mapping, but for some other things. So I started working on TreeShape plugin. Plugin makes it possible to layout any KOffice shapes in tree structure and manage it.

As tree can work with any KOffice shape, I prefer using Ellipses or Rectangles (this simple shapes are well suited for debugging).


Let us see, what tree plugin can do right now:
  • There are four types of layouting shapes: OrgUp, OrgDown, OrgLeft and OrgRight. Also layouts can be combined.
  • Keys 1,2,3,4 change type of tree's layout.
  • You can add new children (by pressing <Tab>) and neighbours (by pressing <Enter>).
  • Trees can be moved from one parent to another. Just select tree and release mouse over the new parent. As you can see this way is not very comfortable, so currently I'm working on more interactive movement.
  • It is possible to undo/redo children moving, adding and deleting.

    And this is in turn in to-do list:
    • Some new layout types similar to XMind ones.
    • Saving/Loading trees.
    • Indicators - icons attached to shapes which display such usefull information as readyness, priority, etc.
    • Comfortable docker widget to control trees.

    01:58, Sunday, 01 August UTC

    July 31, 2010

    Lamarque Souza (lamarque or lvsouza)

    Plasma NM, modem Sony MD300 and more...

    During the time I implemented ModemManager support in Solid I did the tests with my Sony MD300 modem. For anyone to use this modem in Linux do this as root (or use sudo):

    1. Install networkmanager-0.8 and modemmanager-0.4;
    2. Create the file /etc/udev/rules.d/50-md300modem.rules with the follwing contents:

      1. ACTION!="add", GOTO="3G_End"
      2. SUBSYSTEM=="usb_device", ATTRS{idProduct}=="d0cf", ATTRS{idVendor}=="0fce", PROGRAM+="md300modem.sh %p"
      3. SUBSYSTEM=="usb", ATTRS{idProduct}=="d0cf", ATTRS{idVendor}=="0fce", KERNEL=="ttyACM*", SYMLINK+="modem3G-%n"
      4. LABEL="3G_End"
    3. Create the script /lib/udev/md300modem.sh with the following contents:

      1. #!/bin/sh
      2. echo 3 > /sys/$1/device/bConfigurationValue
      3. sleep 3
      4. # enables/activates the modem (turns radio on and registers to operator network).
      5. chat -V -s '' "AT +CFUN=1" 'OK' '' < /dev/ttyACM0 > /dev/ttyACM0
    4. Run: udevadm control --reload-rules;
    5. Click on Plasma NM's system tray icon -> Manage Connections -> Mobile broadband  -> Add -> GSM Connection and use the parameters:

      Number: *99#
      Username: <operator's username>
      Senha: <operator's password>
      APN: <operator's apn>
      Type: Any
      For instance my configuration is as follow:
      Number: *99#
      Nome do usuário: tim
      Senha: tim
      APN: tim.br
      Type: Any
      OBS: some cell phones, like my Samsung i8910, only connects if "Type" is set to "Any". The MD300 connects with any of the types listed.
    6. Hook up the modem to the USB port, wait until it powers up and register itself to the operator network (takes about 30 seconds to do both);
    7. In the Plasma NM initial window clicks on the connection you have created.
    My modem connects only once in ethernet mode (default mode), to connect again I have to remove it from USB port and hook it up again. I do not know why that happens and one guy told me his MD300 does not behave like that. Oddly enough with wvdial and kppp, which uses ppp mode, it does have this problem.

    To make it easier to set up a Mobile Broadband connection I have started to port the nm-applet connection wizard to KDE. It is still in early stage and I am working on it only during weekends. Probably it will be ready for KDE release 4.6 early next year. The initial window is like this:



    It takes some time to understand how both nm-applet wizard and Plasma NM kcm modue work and since I can only work on it during weekends do not expected something usefull until September.

    22:38, Saturday, 31 July UTC

    Jesper K. Pedersen (blackie)

    10-100 times faster thumbnail loading

    Fast - tell me how do you implement a thumbnail loader - well the loading
    and storing of the thumbnails that is?

    Classically you would likely say something that included individual JPG
    files for each thumbnails, and perhaps also something that included
    multithreading.

    Well that is at least how many application does it, and Linux even have a
    standard for it, so applications can share the thumbnails.

    I've implemented a much faster way to do it. This is something like 10-100
    times faster, and I have code to prove it Smiling

    The Short Story
    Store all the thumbnails in one big file, which is way
    faster to navigate for the hard disk, than seeking around just to load a
    few kilo bytes here and there.

    The slightly longer story

    First of all, I didn't come up with this idea, so kudos to whoever
    introduced it to me many years ago - maybe someone planted the idea in my mind
    while I was sleeping Smiling

    I'm no where close to being a hardware kind of guy, so I wont bother you
    with the details or statistics, but the fact is that the hard disk waste
    valuable milliseconds when it has to seek to a new location to load
    data. Just try to create an application which loads dummy data from a bunch
    of different files, and measure how much your application loads a
    second. Now compare that to an application that loads dummy data from one
    big file instead.

    When you want to see the thumbnails in say a photo application like
    KPhotoAlbum, then you are very likely to load them in a specific sequence,
    so if you could get them located on disk in that sequence then the disk
    would not need to skip around when loading.

    I, at least haven't found a way to tell my Linux how to store things in a
    specific order on disk, so the alternative is to store all the thumbnails
    in one big file. That at least from my test seems to be way less
    fragmented.

    Try it out
    OK, don't just trust what I say, try it. Download the demo from
    http://www.kphotoalbum.org/data/ThumbnailLoader.tgz

    compile it using:
    qmake; make

    run it like this:
    ThumbnailLoader new /path/to/the/rootdirectory/of/all/you/images

    you only need to specify the path the first time you run the demo.

    To compare this to the old way of loading thumbnails, you may run the
    demo like:
    ThumbnailLoader old.

    To avoid being cheated by your disk cache, make sure you load in a lot of
    images, and that you scroll a lot around.

    Cheers
    Jesper.

    14:14, Saturday, 31 July UTC

    Brad Hards (bradh)

    OpenChange team meeting

    The OpenChange team had a short online (IRC) meeting on Friday. The meeting record is at http://tracker.openchange.org/projects/openchange/wiki/Meeting_of_2010-07-30

    We're considering holding an "open session" meeting (again on IRC), possibly in a couple of weeks. If you'd be interested in attending, please leave a comment on the best days and times (relative to UTC) so we can accommodate as many people as possible.

    14:08, Saturday, 31 July UTC

    Aaron Seigo (aseigo)

    having made our beds, we now lie in them

    Oh my. Poor Dave Neary. He was just trying to offer some insight into how GNOME gets put together, and it ends up serving as an outlet valve for some pent-up frustration towards Canonical, in this case via a blog entry by Greg DeKoenigsberg.

    Perhaps Dave's presentation could have been a bit "safer" if it had looked at just more recent times, or covered more than just commit rates, but presentation time is limited and, really, any information on how your community works and is put together is invaluable to its health and improvement. If I were part of the GNOME community, I'd be looking for ways to embrace Dave's hard worked for information in positive ways.

    Dave's intentions were undoubtedly good and he put an obvious amount of time and effort into his presentation, but was repaid with a very public and unflattering flame war about something rather tangential to his goals with that presentation. Ouch.

    Tribalism



    Why does this happen? That's a great question, and I'm not sure we can ever have all the answers with perfect accuracy. Maybe we can summarize and approximate, though, and discover useful things as a result. Mark Shuttleworth offers that the problem is tribalism, and that tribalism in the form of fanboyism is Bad(tm). I think Mark hit the heart of the matter.

    Here's an unfortunate part of the truth, though: while Mark rightfully comes out against tribalism, Canonical has, in my experience, been as much a part of fostering tribalism in F/OSS as anyone else. In fact, I'd say they are right there among the leaders in doing so: it's a side effect of their immense drive to build a rabidly loyal community around their brand and their propensity to try tell other communities how to do things (e.g. how to schedule their releases).

    After all, it's pretty meaningless to be a self appointed dictator for life if you don't have a kingdom to dictate, right? (That's said with my tongue placed firmly in my cheek. :)

    Those are rather tribalistic concepts, though, and it is reflected in choices such as Canonical's decision to use launchpad rather than upstream repositories that already exist or how we see Ubuntu LoCo's displacing more diverse Linux interest groups at the local level. It isn't zero-sum, though: Canonical has their reasons and there are benefits that come along with the challenges. I even believe that Canonical's motivations are not conspiratorial in nature, but are similar to those that drive rest of us: making F/OSS awesome. I also recognize that mistakes get made, in spite of those good intentions. Most importantly: Canonical isn't alone in this set of interactions. We are all part of this thing.

    If you are an Ubuntu or Canonical fan (or Mark :) and you read that, it might sting a bit (or maybe even a lot) and the instinct might be to react quickly, negatively and loudly. After all, who the hell am I to say something like that, right? :) Instead, maybe we can step back for a moment, turn off the flamethrowers for a little while (there's lots of time and opportunity to use them later if we wish to ;) and really think about the root causes of our tribalism. Much of it is going to turn out to be innocent, but all of it will show where we have room for improvement.

    On Being Able To Admit Failure



    One thing I've learned in my travels as someone who dabbles from time to time in providing leadership is that in doing so your faults will be put on display for everyone to see. We are each imperfect, we all screw up from time to time and being front-and-center means our screw ups get put front-and-center, too. It is humbling. It can be important to recognize when it happens and (even if it takes a while) come back and go "yep, I screwed up, let's see how we can improve on that going forward..." At that point we all grow and become better people for it. If we do that within our Free software communities, our communities will also become better for it. Linus' ability to do that makes up for many other faults he may exhibit from time to time.

    Someone asked me the other day on the kde-promo list how KDE people can expect to get the KDE branding terms "right" when even I don't always get it right! I responded with the most honest answer I had: I still, even now, make mistakes when it comes to the branding terms, in large part because I've been doing the "KDE thing" for so long that it's like an old dog with new tricks. I asked them to continue to point out when I get it wrong so I can improve. It's often hard to say things like that without hedging, especially for those of us with hard heads and big hearts.

    I've also discovered that, sadly, I'm going to offend or let down those I love dearly from time to time even though I really don't mean to and don't want to. When that happens, it's often more important to just say I'm sorry without worrying about defending what I did, even if I think it was a misunderstanding or justifiable. I have been working for many years on being able to prioritize the well being of those I care about more than I do about being "right". Let me be honest: it doesn't come naturally to me, and I still fail at times. But ... I also do manage to say "I'm sorry", to look for root causes without looking for blame to attach to it, and most importantly to me: to try and work on improvements that address root issues. I keep trying to remind myself: "I am an imperfect man reaching for the unattainable goal of perfection; and I am inching closer to never getting there every day."

    Ok, so what's my point, already? Well ...

    When Mark wrote about tribalism, Máirín dredged up in the comments section an unfortunate and regrettable public gaffe on Mark's part from the past and asked him if he'd apologized for that yet. Maybe Mark should consider doing just that, even if he doesn't consider what happened to be wrong in his own mind. It could help drain away some of the poison out there that is used to fuel some of those tribal fires. It certainly can't hurt.

    In fact, all of those who have pointed fingers or defended themselves loudly, including (but certainly not limited to) Greg, could maybe try to step aside from their own correctness and ask what are the shared root causes that lead to this state of affairs. Can we instead create discussions with ourselves and with each other that reach for understand but don't include statements of blame or accusation? It is possible to discover the mechanisms of failure in a relationship and come up with new possible solutions to try in blame-neutral ways.

    That's just another way of saying that others may be responsible for (a large or small) part of the current dynamic, but we don't need to use that as an excuse to sidestep responsibility for the roles we play in it or as a way to avoid addressing the issues altogether. After all, what's more important: the moral high ground in our own little kingdoms of "Me, Myself and I" or forging a stronger and unstoppable thing together?

    On Being Part Of The Problem Solution



    The good news is that when we are one of the people caught up in a problem, intentionally or not, we can be part of the solution. Yes, being part of the problem is an opportunity. To illustrate: we may not have invented proprietary software ourselves, but we are/were caught in the midst of the consequences of a world that was dominated by proprietary software; by writing Free software, we are creating part of the solution to the negative effects of that situation.

    In the questioning of Canonical's contribution, right now I see a lot of people trying to make the case that they aren't a part of the problem or that others are more a part of the problem than they are. Quite clearly they axiomatically are all shareholders in whatever failure is happening (the flamefest itself is a failure, imho). It is axiomatic because the problem is being driven by how communities are interacting, and the people pointing fingers and making defenses are part of those communities. Some are even responsible for leading the relationship components of those communities. They could be identifying what the challenges are and being part of the solution, regardless of who is contributing what to those challenges in the first place.

    If each of the parties (GNOME, Canonical, Red Hat, whoever else) involved took internal stock of the situation they might identify all kinds of things they can each do to improve. How much better than writing witty blog posts that won't alter the status quo that would be! Leadership will be self-evident when people start describing and implementing such improvements, regardless of whether others do so first, later or never.

    On Alignment



    Starting with the alignment of priorities and agreeing on the context for the conversation would be a reasonable place to start, perhaps. To illustrate what I mean by that: Jono Bacon
    used the term "upstream" in his response to the issue in a way that is very different from what the people leveling the complaints at Canonical are. Jono used upstream in terms of Canonical's own efforts: their software developers are upstream of their packagers. However, it seems evident to me that Greg and others are using the term in the context of the global F/OSS economy, where in this case GNOME is the upstream of Canonical. It's the difference between looking at the supply chain within one particular company's factory, and looking at the role of that factory in the greater economy in which it operates.

    Due to this difference in context, people are engaged in a conversation about upstream contribution in which both are 'right' in terms of the context they have chosen to speak from. This also means, though, that neither party is really addressing the same issue together. As long as those kinds of context and priority differences are not addressed so that a common conversation can be had, it will be a very long, hard, painful and probably unfruitful conversation.

    I've been caught in many such conversations in the past with others in F/OSS. It happens; it's also fixable.

    Why Care?



    I believe it to be important that we care about these things because they are doing large amounts of unintended damage to F/OSS. But as my step-father used to tell me, "When you point a finger at someone else, you are pointing three fingers back at your own self." (Try it: point at something with your index finger, arm extended. :)

    So let me address those three-fingers-pointing-at-myself. To be honest: the relationship between KDE and Canonical has not always been fruitful or friendly, ditto for KDE and Red Hat or KDE and GNOME. Even within KDE we have our moments of discord. It's not easy, it's not simple and I do not want to come off like I'm pretending it is or that my or KDE's track record is perfect either. KDE has managed to improve many of these things, some of them immensely though certainly not to perfection, but you know what is really unfortunate and sad when I reflect up on that? The root causes, tribalism and selfish misalignment of priorities relative to each other, were / are the same as those at the heart of today's tempest in a teapot over Canonical's upstream contribution and/or lack thereof. F/OSS has yet to truly learn the lessons we need to. We keep repeating the same unhealthy behaviors, we keep enabling each other in doing so.

    I have to say that it was really tempting to delve into an analysis of what, in my opinion, the specific behaviors are that led to this particular blog storm, but when I thought about it I realized that it's not really my place to do so. After all, I'm not a direct stakeholder in this particular scenario and have not been invited to enter into the middle of what amounts to other people's relationship. So instead, let me get a little philosophical about what it might take to step away from our feudalistic ways:

    We ought to be looking for F/OSS communities who can lead in demonstrating positive and useful ways of dealing with these somewhat inevitable moments of conflict. We need to encourage those who aren't leading in this way to improve their game; we need to give each other the opportunity to improve our game by avoiding blame games. We need to support each other in our hard times and our moments of brilliant alignment. For those who insist on tribalism, the rest of us need to move past them and minimize their impact and importance in the F/OSS ecosystem, so as to limit the harm they perpetuate.

    We need to learn how to accept that someone is going to be a fan of $DISTRO or $PROJECT without using that against them. We need to learn how to be a fan of $DISTRO or $PROJECT without looking for ways to push for its advantage at the expense of F/OSS in general. We need to learn to recognize each others strengths, as well as to stop claiming that we're strong where we aren't. We need to learn to disagree without sabotaging each other. We need to learn how to cooperate, even sometimes by making local compromises to achieve a higher level of global win. We should be looking at how to put together what we are each doing well into a larger whole, even when we are also competing elsewhere. We can both compete and cooperate without dragging each other down in the process.

    The path beyond tribalism is, in my humble opinion, to realize that despite our love for KDE, GNOME, Ubuntu, Red Hat, Suse and/or fluffy bunnies we must each hold aloft a common goal that trumps all else: F/OSS must succeed. The world is depending on us to do that, because the world needs Freedom, and Free software is an important part of that.

    That is the challenge we have before us. Sort of puts things into perspective, doesn't it?

    But Before I go ..



    Kids are smart. They will learn that when you do something bad you get attention even if it is negative. If they don't get the attention all children need in the course of growing up, they put this together in their head and start to look for ways to break "the rules" to get that attention. To be fair, some adults do that too. :) As an adult who plays a role in the child's life (a parent, especially), that pattern can be prevented by (among other things) paying attention to the things they do that are positive.

    In that spirit, I'd like to end this blog post by giving a shout out to a few of the communities out there that are doing good things. Good work deserves attention and recognition, and you shouldn't have to be in the middle of a controversy to get it.

    I'm thinking of OpenSuse, for instance: they make hard decisions and are pretty open about how difficult things can be internally at times, but they've consistently been a pleasure to work with, even through difficult times.

    I'm thinking of Pardus, a small but hardworking group of people making an awesome distribution aimed primarily at their own region, but who are also doing all kinds of wonderful things technology wise both in their project and upstream.

    I'm thinking of Red Flag who, despite other possible negatives, have also been contributing more and more upstream over time.

    I'm thinking of Mandriva who, despite their financial bumps over time, have not only never caused grief for us as an upstream project but have contributed significantly.

    I'm thinking of the numerous small and medium size businesses who aren't distributions but who are as important as many of the distros in making sure upstream keeps ticking. I'm also thinking about you, reading this blog entry because you care enough about these issues to do so with an open mind.


    p.s. I'm concerned, having re-read it (and edited it several times), that this blog entry could come across as preachy. I really hope it doesn't, but I do recognize that my communication skills have limits to them and some may choose to read it that way. It feels rather unsafe to push the "Publish Post" button, and honestly I am hesitant to do so. It seems, however, that these are things that need to be said, and I can only hope that some of it is useful and gets through to those who will make things better than they are now. Deep breath time!

    Love and with hope for all the best things in life, Aaron.

    01:31, Saturday, 31 July UTC

    Michael Pyne (mpyne)

    Big update collection

    Unfortunately I haven’t made any blog updates in awhile. I’ve been very busy between work and school (and I will likely spend this weekend working on a 20 page project that I’ve written 0 pages for ;). That doesn’t mean I have nothing to report though…

    First off, I have renamed kdesvn-build to kdesrc-build to reflect the fact that it builds from Git-based software repositories. In conjunction I released kdesrc-build 1.12 which has various minor improvements, including a few Git improvements.

    I’ve complained about my car breaking down. It’s fixed, although I will be selling it now (my wife and I were debating the merits of getting an improved car for awhile before, this incident sealed the decision).

    Just today I’ve committed a new feature to JuK, the sadly neglected KDE Software Compilation music manager. Now you can use the scroll wheel in the track announcement popup to quickly switch tracks without having to use the Next/Prev buttons. It’s probably already in every other media player with a playlist, but it’s at least in JuK now. Note that this is a 4.6 new feature, not 4.5.

    I’ve also been “reviewing” a patch to further remove Qt3 support code from JuK, which I will try to clean up and get comitted this release cycle. The big thing I still need to do is to finally convert from K3ListView to a real Model/View architecture to finally be rid of Qt3Support. Help is always appreciated btw =D

    Burkhard Lück, the documentation super-hero, has been improving JuK documentation for me, but I still need to make some changes that he’s requested to bring the docs closer to 2008-era (let alone 2010) :(

    That’s another good “intro to KDE Platform” kind of job by the way, it’s how I got introducing into coding for JuK myself. ;)

    01:05, Saturday, 31 July UTC

    July 30, 2010

    A. L. Spehr (blauzahl)

    A new BugDay! this Sunday

    Looking for a good way to contribute and got some spare time this weekend? KDE BugSquad is holding a Bug Day revival this Sunday 1st of August and still looking for people who'd like to help out with getting Dolphin bugs under control.

    We'll be gathering in our IRC channel (#kde-bugs) starting around 10:00 AM european time zone. As always, no coding skills required. All you need is a recent version of our beloved KDE Software Compilation. Senior bug triagers will be around to help you get started.

    More info on: http://techbase.kde.org/Contribute/Bugsquad/BugDays/DolphinDay1 (available soon)

    See you there! :-)

    Can't make it then? That's ok, we'll have another. Promise.

    But feel free to drop by anytime, bug reports always come in, and somebody has to look at all those duplicates!

    Then the big question: do we hold our Bof in the back of a bus next year too? It makes it hard to take a group photo!

    23:22, Friday, 30 July UTC

    Jason A. Donenfeld (zx2c4/jdonenfeld)

    Interfacing CGit and Gitolite

    As many of you know, the KDE Project is transitioning to using Git with Gitolite and CGit. As such, I thought I’d update my aging Gitweb/posix-permissions installation of git to use CGit and Gitolite, and now my public git repository is kicking away. (If you’d like commit access any place or would like to host your own repo on my server, drop me a line.)

    Since Gitolite manages git repositories, it has the option of generating the necessary information for Git’s shipped gitweb. This includes making a static list of repository names that should be included in gitweb as well as optionally adding the gitweb.owner entry inside .git/config and the description file at .git/description. The static list of repository names is boring and standard and easy. The owner and description specifications are standards set by the Git project for this kind of information. Hence, Gitolite supports interfacing with them.

    Meanwhile, CGit uses its own configuration format for determining the owner and description and repository path. For interfacing with Gitolite, in the past I have created a hook that writes out a CGit-formated configuration file, which is then included in the main cgitrc with the include directive. Essentially I had to do this:

    gitcode@starfox ~ $ cat web/cgit/generaterepos.sh 
    #!/bin/sh
     
    cd $(dirname "$0")
    rm -f repos.tmp
     
    cat ~/projects.list | while read gitname; do
            name=${gitname%.*}
            fullpath=/home/gitcode/repositories/$gitname
            owner=$(git --git-dir=$fullpath config --get gitweb.owner)
            desc=$(cat $fullpath/description)
            (
                    echo repo.url=$name
                    echo repo.name=$name
                    echo repo.path=$fullpath
                    echo repo.desc=$desc
                    echo repo.owner=$owner
                    echo repo.enable-log-filecount=1
                    echo repo.enable-log-linecount=1
            ) >> repos.tmp
    done
     
    mv repos.tmp repos
     
    gitcode@starfox ~ $ tail -n 1 web/cgit/cgitrc 
    include=/home/gitcode/web/cgit/repos
     
    gitcode@starfox ~ $ cat repositories/gitolite-admin.git/hooks/post-update.secondary 
    #!/bin/sh
    exec /home/gitcode/web/cgit/generaterepos.sh

    This worked decently, but it was cumbersome and ugly, and was likely not to scale as features in both Gitolite and CGit are added and changed. Luckily, CGit supports the scan-path option, which builds an internal list of repositories automatically by scanning a directory for git folders. One such solution for integrating with Gitolite would be to simply point scan-path at Gitolite’s repository directory. This works fine, but it has three main shortcomings, which I’ve addressed this in a generic non-Gitolite-specific way in three patches. Let’s walk through them one by one.

    projects-list

    We don’t want all Gitolite repositories showing up on CGit, and Gitolite provides a generic mechanism for controlling this: it writes a list of all the repositories selected for Gitweb to a file called projects.list. It’s just a flat file with each repository’s name written on a new line:

    CheeseWhiz.git
    Geoemail.git
    MyCoolThangs.git
    

    So, what about augmenting CGit’s scan-path feature with another setting called “project-list” that points to this file? That’s what this patch does. If project-list is set before scan-path is set, then scan-path only scans the git folders at project-list/${a line in the project-list file}. Problem solved, and this is a pretty generic way of doing it too.

    git-suffix

    Most people store git repositories on disk at MyGitRepository.git. Notice the .git ending. However, most people prefer to see it listed as just “MyGitRepository” and they especially would like to clone it at gituser@domain.com:MyGitRepository, without needing the .git ending. Usually, CGit’s scan-path infers the repository name directly from the folder name. This patch adds a setting called “remove-suffix” that, if set to 1 (default is 0) before scan-path is set, will remove the .git suffix from the repository name and url while still pointing to the correct physical path. This as well is fairly generic and not specific to Gitolite or Gitweb, but rather Git’s usual conventions.

    config-owner

    CGit’s scan-path infers the owner of the repository from the posix owner’s UID name. But there is an additional Git standard for overriding this for any interface: the “gitweb.owner” configuration key in .git/config, which Gitolite understands and respects, as well as Gitweb. This patch simply calls Git’s internal C functions for fetching this information from the current repository’s config, and prefers this as the owner to the posix owner’s UID name. If gitweb.owner is not set in the configuration, it falls back to the posix owner’s UID name. This is a standard Git behavior. This occurs only for scan-path — cgitrc specified owners are preferred over these former two, obviously. Again, this configuration standard has been determined by the Git project, and both Gitolite and Gitweb respect it. So, this patch adds support inside CGit for it.

    it works

    Now instead of the include and the ugly set of scripts and hooks, I can just place this at the bottom of my cgitrc:

    remove-suffix=1
    project-list=/home/gitcode/projects.list
    scan-path=/home/gitcode/repositories
    

    and this integrates perfectly with Gitolite. All is harmonious in the Git universe.

    On top of all this, I’ve cooked up a wicked good .htaccess file for CGit that allows me to have anonymous http pull at the same time as it rewrites the CGit urls to be pretty. Check it out:

    Options FollowSymlinks ExecCGI
     
    DirectoryIndex cgit.cgi
    Allow from all
    Order allow,deny
     
    RewriteEngine on
     
    SetEnv GIT_PROJECT_ROOT=/home/gitcode/repositories
     
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d 
    RewriteRule "^(.*)/(.*)/(HEAD|info/refs|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack)$" /git-http-backend.cgi/$1.git/$2 [NS,L,QSA]
     
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^.* /cgit.cgi/$0 [L,PT,NS]

    A strange combination of stopping internal redirects and partial rewritings and odd stop conditions has made it so that the request gets forwarded and reformatted to git-http-backend if and only if it is first valid with cgit.cgi. Is this crackable? Can anyone figure out a backdoor to grab a repository that isn’t in projects.list?

    I’ve also written a super generic script for uploading new repositories to my gitolite/cgit installation. From a git working directory, I run ~/Projects/uploadNewGit.sh "This is a description of my new git repo.", and wham-shabam, all the permissions get set and everything is uploaded just fine. Here is uploadNewGit, the latest version of which you can always find in my GitTools repository:

    #!/bin/sh
     
    GITOLITE_ADMIN="$HOME/Projects/gitolite-admin"
     
    gitdir=$(readlink -f "$(pwd)")
    name=`basename "$gitdir" | cut -d / -f 2 | cut -d ' ' -f 1`
    description="$1"
     
    if [ ! -d "$gitdir/.git" ]; then
            echo Not a git repo.
            exit 1
    fi
    if [ -z "$description" ]; then
            echo You need to specify a description argument.
            exit 1
    fi
     
    pushd "$GITOLITE_ADMIN/conf" > /dev/null
    echo "Writing config..."
    (echo
    echo "  repo    $name"
    echo "          RW+CD   =   $(whoami)"
    echo "          R       =   @all"
    echo "          $name \"$(git config --get user.name)\" = \"$description\"") >> gitolite.conf
    git commit -a -m "Adding $name to repository."
    git push
    popd > /dev/null
     
    url=`git --git-dir=$GITOLITE_ADMIN/.git remote -v | grep push | cut -f 2 | cut -d ' ' -f 1 | sed "s/$(basename $GITOLITE_ADMIN)/$name/"`
    git remote add origin $url
    git push origin master
    git push --all
    git push --tags

    (As a side note, I’m not really sure the best way to quote commands inside of commands with variables that have spaces. something=$(command $(othercommand $argument)) has issues if argument has a space or if othercommand produces something with a space or if command produces something with a space (not totally certain about the latter two — I should check). But I can’t do this: something=”$(command “$(othercommand “$argument”)”)” because of obvious quoting problems. What’s the common solution to this? I’ve been using an awkward combination of the backtick operator `…` and the $(…) syntax but the backtick has some weird rules too. What’s the deal? Can somebody point me in a good place to read about this?)

    Anyway, most of what I’ve written about in this post is new to me. Or at the very least, I’m a bit uneasy. So if you have any suggestions, by all means please tell me. I’m looking forward to seeing what the KDE sysadmins do in the end. Hopefully the CGit authors accept my patches.

    Update: After some back and forth with Lars, the CGit maintainer, I’ve added a few more patches, including putting the gitweb.owner functionality behind configuration setting and also caching the scan, among various other improvements. You can check out all the commits I’ve made on this at the cgit for my cgit clone.

    22:50, Friday, 30 July UTC

    Richard Dale

    Two Tribes

    It's official the combined KDE Akademy and Gnome GAUDEC conferences will be held in Berlin in 2011, next year and this is great news! I played a small part in organising the joint conference in Gran Canaria in 2009, and really enjoyed working with the Gnome guys most of whom I hadn't meet before, as well as the familiar KDE people. It was great fun to see how it turned out. I don't think anyone really knew in advance - we didn't know if too much collaboration would spoil the 'community bonding' aspects of the conference and their individual identities. Or maybe too little collaboration would increase the distance between the two communities. In the end I thought the collaboration aspects could have been better, indeed like the WiFi could have been better - there is always something you can improve at these conferences, but what the heck, by and large it was mostly pretty good.

    I enjoyed being able to go to both presentations, and some of my favourite ones, like the MeeGo^h^h^hMoblin user experience talk in the mobile track, came from the Gnome side. Both projects are facing the problem of how to you merge your desktop technology with the upcoming Smartphone/Small devices that run platforms such as Android or Meego.

    A consequence of stresses like upstream vs downstream or mobile vs desktop, is that Dave Neary's recent survey of Gnome contributors has given rise to much discussion and flaming about Canonical's contribution. One from Mark Shuttleworth called Tribalism is the enemy within, which is worth a read. That addresses tribalism within the Gnome community, and that is clearly a bad thing.

    Another good post from Jono Bacon RED HAT, CANONICAL AND GNOME CONTRIBUTIONS included this from Dylan Macall, which made a good point:

    "..This whole thing is really putting forwards an issue Gnome has right now: they can’t, as a community, decide whether they like the idea of external projects building new environments on the Gnome platform. (Case in point: Meego for netbooks).
    I think there’s one camp that thinks Gnome should be a user-facing product, with its own special branding and its own distinctive look that everything ships in pristine condition. (I’ll inject my opinion in brackets here: I think that entirely defeats the purpose of having multiple distributions).

    Then there’s another camp that sees Gnome as a starting point with lots of handy tools (and common modules) for distributions to build operating systems. For example, Unity, Meego, Jolicloud, UNR…
    That first camp sees Gnome as a monolithic project; only internal work is worthy. The latter camp sees Gnome as something akin to Gnu.."

    I think you could have exactly the same discussion about the KDE project and what it's relationship with MeeGo should be. Does KDE consist of a lot of useful tools and libraries that we should encourage as many other projects as possible to use? Or should we concentrate mainly on a cohesive desktop experience? Are the two aims incompatible? I don't know..

    I hope we can minimise Gnome vs KDE tribalism too, and I'm looking forward to another combined conference, where we can integrate the communities better (and in the process have great parties involving much beer drinking of course). I was slightly disappointed that Gnome 3.0 has been delayed, and I really wish them good luck in getting it out of the door. It is not true at all, that if Gnome does worse, then KDE will do better. If both projects succeed it is more like '1 + 1 = 3' or if one project fails it is '1 + 1 = 0.5'. We now have much infrastructure in common and need each other to succeed so let's "Relax"..

    19:59, Friday, 30 July UTC

    Arno Rehn (pumphaus)

    Java bindings?

    Since the C# bindings are apparently not really used/wanted by anyone (except for some Windows people – but that’s really not my main development platform) I thought that maybe some more people are interested in Java bindings.

    There was a poll on kdedevelopers.org two years ago that showed Java ahead of Ruby and C# – but it doesn’t seem to be really representative: there are at least some Ruby plasmoids on kde-look.org, but none in C# (which was still ahead of Ruby). Given that Trolltech/Nokia abandoned QtJambi I’m not too sure about Java bindings either.

    So I’m asking the community directly before I start putting too much work into a project that noone really wants: So far we have (active) bindings projects for Python, Ruby and Perl – is there any demand for Qt/KDE Java bindings in the community? Or if not for Java, for any other language/platform?

    Looking forward to your comments :)

    18:22, Friday, 30 July UTC

    Thomas Thym (ungethym)

    KDE release counter

    Dion just made new release counter for 4.5.

    Just add a HTML/JavaScript gadget to your blog:

    For the square banner:

    <a href="http://kde.org/" target="_blank"><img src="http://e2-productions.com/countdown/counter45-square.php" alt="KDE SC 4.5 Release Counter" /></a>


    KDE SC 4.5 Release Counter

    For the long banner:

    <a href="http://kde.org/" target="_blank"><img src="http://e2-productions.com/countdown/counter45-long.php" alt="KDE SC 4.5 Release Counter" /></a>


    KDE SC 4.5 Release Counter

    17:28, Friday, 30 July UTC

    Marco Martin (notmart)

    Documentation: it has to be done

    Plasma has a wonderful theming engine, that enables the creation of a really stunning visual appearance, with a great amount of customizability, just look at what is available right now, to not mention that being vector based makes the widget set pretty flexible and able to be used on really different hardware form factors with different sizes and dpi.

    But we're developers and we like to write code, hack on stuff, we often forget to document things, and this is an area that really can get better.

    Yesterday I've forced myself to look at the quite incomplete and outdate documentation for the Plasma theme system and I've looked file by file, element by element and completed and ordered the whole theme.

    Now if you have any doubt on the Plasma theme structure, just go to the relevant techbase page, and you'll find the complete list of every file and every element in every file, updated to the upcoming 4.5 release. this should ease a lot the construction of themes.

    It has been a long and painful work, of which developers may really want to avoid it, but it incredibly pays the effort, because it's a really important part of the elegance we are trying to reach. A complete, pretty and documented framework is what is elegant to a quite relevant part of our audience: developers that are approaching the platform for the first time.

    Now we are restructuring the techbase page for Plasma, moving here the pages that makes more sense here, having the two wikis more in focus and comprehensible.

    If you are interested, if you are trying to approach the development in Plasma and have difficulties to grok some of the concepts, if you already work on some plasma aspects such as plasmoids, just stop on #plasma on freenode and you can give an hand in the documenting effort, being tutorials, wiki pages or API docs, you'll learn quite a lot of the internals in the process and will make easier for others to learn.

    15:23, Friday, 30 July UTC

    Aaron Seigo (aseigo)

    Plasma in KDE's Wikis

    The Plasma team tries to care about documentation. We always fall short of our own high expectations, in part because they are high and in part because we don't have a technical writer in the project. What a difference just one technical writer as a Plasma team member would make!

    Still, we have quite a bit of documentation around. This includes API docs, examples and Techbase tutorials. I'm quite proud of the comprehensive documentation we have for things like the desktop scripting, Javascript API and Theme contents (thanks to Marco for updating that one today!) as well as the growing number of examples we are adding.

    We have, however, been committing two sins: we've been abusing Techbase as a project community wiki and we haven't been writing end user documentation. We're fixing that, but before I go into details I'd like to point you to Dominik's excellent reminder-by-blog regarding the mission of each of KDE's public wikis. To quote the summary from that blog entry of his:

    • TechBase: The primary place for high quality technical information about KDE targeted at 3rd party developers, ISVs and system administrators.

    • Community: The working area for the KDE community. It provides a place for sharing information within the community and coordinating community teams.

    • UserBase: The home for KDE users and enthusiasts. It provides high quality information for end users on how to use KDE applications.



    Community.KDE.org


    So everything we have had under Projects/Plasma on Techbase really is supposed to be on community.kde.org. We started, and are very nearly complete, that transition. You can see the results on community.kde.org/Plasma. We've used this as an opportunity to freshen up and reorganize some of the content.

    If you are involved in a project that has content under techbase.kde.org/Projects, please also consider moving it over sooner rather than later. I did a few pages a day (so that I didn't get bored by it ;), spending no more than 30 minutes or so at a time doing so. Marco also pitched in with the Theme Details, which has now moved to being a tutorial and out of our community coordination wiki space. So it's very doable, you just need to budget a little bit of time. Best part is that it taxes no brain cells, so makes a great end- or beginning-of-day task for when you'd like to do something KDE but can't bring yourself to do any heavier lifting. :)


    All Hail KDE User Documentation Writers!



    Next up is user documentation. While in Finland for Akademy 2010 I made a personal commitment to Anne Wilson, one of this year's Akademy Award rockstars, to write user documentation on Userbase for Plasma. It's not quite as selfless as that may sound at first. You see, there are those who would like to see Userbase become the new spawning ground for end user documentation.

    This is due to the fact that there are, and have almost always been, just a small group of absolute heroes who have worked on KDE documentation through the years. They have done an awesome job with the resources they have to work with. In fact, one of the key players thus far in documenting apps based on the KDE Platform v4, Burkhard Lück, was also recognized with an Akademy Award this year. There is only so much a small group can do, however, and our software moves quickly. In addition, our users are more and more web-centric when it comes to looking for information.

    Wouldn't it be great if we had a way for more people to participate easily in adding to KDE user documentation? How about providing our documentation in a more familiar web format as well? Enter Userbase, a mediawiki-driven site that may just be a key part of the answer. It has a passionate and committed project driver behind it as well in the form of Anne.

    The goal is to therefore put more and more user documentation on Userbase where it can be groomed and improved into stunning user documentation. There may be some nay-sayers who think that user documentation is a work of art (and I agree to an extent) and requires skill to do well (again, I agree). The issue, however, is that it's too difficult for those with the skills and sense of the art to get involved. That difficulty is in part perceived ("how do I contribute?" is such a common question) and in part real (barriers not low enough). Remember that many people said the same thing regarding art and skill about encyclopedias and maps. Turns out this kind of content creation does work pretty damn well. Hello, Wikipedia. Hello, OpenStreetMap.

    Realizing The Dream



    For this dream to enter reality, though, several things were needed. Translation is a solved issue now from what I understand (kudos to those who got that going!), but still outstanding was the ability to generate offline versions of the contents of Userbase so that we don't require going online every time you want some documentation about a KDE application. There was the intent and the desire to work on this, and even a good start to it.

    So I decided that out of respect for our users and for the work people were putting into Userbase that I should put some of my own skin into the game as well. So I told Anne that if they got the offline creation of the documentation working that I'd document on Userbase how Plasma Activities work from an end user perspective.

    Well, guess what Anne and her co-conspirator Ingo Malchow have managed to do? Yep, they've got automatable offline document creation of Userbase content figured out. There's a remaining issue of whether to use an online service that exists outside of KDE for this, or to set up our own installation of the same (Free! :) software on one of our own servers. That's an implementation detail, though. The hard work has been accomplished in my opinion. Which triggers my commitment.

    So I will soon be starting to work on Plasma documentation regarding Activities on Userbase in the Desktop area. I also plan on tidying up the organization of the content that is already there as I go. It will take me several weeks, I imagine, to complete this task. I also hope that by throwing some of my energy into it, that it will encourage others to follow suit. Particularly those amongst our users who are reasonable writers; and remember: if you are concerned about your English skills, it's a wiki .. we can help fix errors if/when they appear. We appreciate content added to the point that it wouldn't even cross our minds to think poorly about good content that happens to have a few English mistakes. We also will need the English content translated so that we can offer this much needed documentation to all of our users across this blue marble we live on together.

    I'll keep you all updated regarding my progress and what I learn as I go through it. Anne and I also discussed the possibility of doing Documentation Days, similar to how we used to do Techbase Days (which would be nice to start up again as well) and the very successful Bug Days.

    (Speaking of which, did you know that Bug Days are starting up again? Yep! Next one is the 1st of August, so be sure to mark it on your calendar and show up for some bugtastic fun. :)

    03:20, Friday, 30 July UTC

    Lydia Pintscher (Nightrose)

    in need of some love and dedication

    When walking in a big group of people you have to check every now and then for the slower ones so you don’t leave them behind and lose them. It’s the same in a community like KDE. Every now and then you have to check if everyone can still keep up and if not take the necessary steps. That’s why for the second time now I’ve asked KDE developers to tell me which parts of KDE they think really needs some new blood or more helping hands. This is the list of answers I got:

    • KDE bindings needs a maintainer for PHPQt and some helping hands for Qyoto/Kimono (the C# bindings). – contact kde-bindings@kde.org
    • KDEPIM looking for someone to work on Akgregator and the Kontact shell. – contact the kde-pim mailing list
    • Juk could benefit from a port to actual KDE Platform 4 technologies (away from KDE3 Support and possibly port Bangarang’s Nepomuk storage to Juk). – contact the kde-multimedia list
    • KOffice is in need of people poking Karbon and Kivio. – contact the koffice mailing list
    • KCalc, KFloppy, Kdf, KTimer and Sweeper from kdeutils do not have maintainers at the moment. Most of these applications are almost unused, but they haven’t been excluded from the module and might at least provide some fun to newcomers. – contact kde-utils-devel@kde.org
    • Okular could use some help fixing crashes and finishing features. – contact aacid@kde.org
    • UserBase is looking for people to help improve documentation. Tasks and guidelines are available on http://userbase.kde.org/Tasks_and_Tools. – contact annew@kde.org

    Quite the mix – surely there’s something exciting in there for everyone. So if you are someone who wants to contribute to KDE and looking for a place to start or an experienced contributor looking for a new project, this is where your help would be really appreciated. Choose your direction and get your hands dirty ;-)

    street sign in china town

    01:11, Friday, 30 July UTC

    Mario Fux (unormal)

    Question to the KDE multimedia meeting participants

    If you were a participant of this years KDE multimedia meeting I would be interested in your opinion:

    As you probably know this was the second kde meeting I organized and I plan to do another one next year (btw I got today the OK of a certain person and I think this means the topic for next years meeting is set but more about this in the following weeks). What do you think if I would earn some money with the organization of the next meeting.

    As I like or love to organize such meetings and I doesn’t seem to be that bad in this I’d like to organize another and another and … You see ;-). But even if it’s a lot of fun it’s also work and time consuming work nonetheless. For the meeting this year it took a good month of time to organize everything (incl. the meeting time). The whole amout of time is or was distributed over half a year.

    And the other thing is that I need to eat (;-), pay the bills and as I’m moving to my girlfriend and my studies end in the next year or two a family is not that far away. And that’s another reason I’d like to professionalize the meeting, make a conference/sprint out of it. An annual one. And don’t missunderstand me: I’d don’t want to become rich on the shoulders of kde developers and/or the KDE e.V. The contrary I starting to plan and search for sponsors much earlier this time to decrease the amount of money the e.V. "needs" to sponsor.

    Oh and if or when you’re waiting for my next "kde work day" blog. It’s in the making but as I’m moving (the whole room is full of stuff to package ;-) some stuff delays a bit. And there’s anoher idea floating in my mind. Something somehow kde related but not code related and something for the kids and probably something to play and something about Konqi the dragon but …

    Oh and I’ll do something like (yes, I like the word "something" ;-) a qt and kde course in my local linux user group… Oh and this is the last oh: I’ll do an english course in the next semester to meliorate my english grammar. Hopefully to your pleasure as well ;-).

    00:11, Friday, 30 July UTC

    July 29, 2010

    Marco Mentasti (mentasti)

    KateSQL, a new plugin for Kate

    Hello,

    today i will show you a new plugin for Kate, called KateSQL.
    As you may have guessed, it brings to Kate the basic features of an SQL client, allowing you to open connections, execute queries, and display result data from SELECT statements or stored procedures.
    Since this plugin makes an extreme use of the Qt Sql module, most of database drivers are supported..

    Said this, let me explain how it works..

    Kate MainWindow with KateSQL widgets

    First of all, you have to create a new db connection through a simple wizard, specifying driver, connection parameters (hostname, username, password, etc…), and a descriptive name, that KateSQL will use as identifier.
    Done this, what you need to do is just select the query text in the editor and press F5 (or your preferred shortcut). The whole text will be executed through the selected connection.

    For SQL output, two toolbox are disposed in the bottom area:

    • The first will show messages returned from the server (errors in red, others in green, like number of affected rows).
    • The second contains a table view with a custom model associated, to show resultsets of a query. This custom model does nothing more than a QSqlQueryModel, only provides colors and formatting for each cell..

    Ah, about this, my last commit implements a configuration widget that let you choose colors and font styles for text fields, numbers, blobs, nulls, booleans and dates… cool, yeah? :)

    KateSQL Configuration Dialog

    Last but not least, on the left panel you can find a basic and useful schema browser, that show the tree schema of the database connection currently selected. With this tree widget you can browse through tables, system tables and views, up to individual fields. obviously, primary key fields are distinguished by the classic yellow key icon.

    Currently, there are few problems with multiple query handling.. Some engines doesn’t supports it natively, others can receive queries separated by a semicolon, but the QSqlQueryModel can handle only one resultset at time.. probably the best solution is to parse the text, split queries, and execute them separately.. Surely, this feature will be implemented soon.
    Stay tuned!

    Of course, if you want to help us with development, you are welcome!

    23:45, Thursday, 29 July UTC

    Michael Leupold (lemma)

    KDE SC 4.5 Release Party in Stuttgart

    As blogged about by Lydia, we'll be having a release party in Stuttgart to celebrate KDE SC 4.5. Here I am with some details about the event.

    • Date and time: Saturay 7th of August, 18:00.
    • Location: Letzte Instanz, Stuttgart-Untertürkheim (next to the train station)
    • Activities: Conversation, having food, drinking, party (!), party more (!!)

    If you live anywhere in the Baden-Württemberg region, be sure to not miss out on this one, no matter if you're a contributor, a happy user or a spouse (who is a happy user).

    Now, just three important things I need to add:

    • If you take part, please add your name on the KDE Community Wiki page (in time!) so I can make sure there's enough room for every participant.
    • As there are quite some people attending, there might be a good chance rides can be shared. If possible, please add your information to the ride sharing section as well.
    • This is not the sprint I've been secretly bugging people about (more information on that to be released in one of my next blogs).


    21:43, Thursday, 29 July UTC

    Jonathan Riddell (riddell)

    New Kubuntu Website, Canoeing in Prague

    After many months kubuntu.org got a new look, complete with new logo. Many thanks to Ofir for his patience in seeing this through.


    During the Platform sprint in Prague I took Aurelien Gateau, doko and a couple of nice chaps from SuSE Prague canoeing on the awesome whitewater course near the city centre.

    Looking confident at the top

    This flatwater is easy

    King of the wave

    This blury photo is the last anyone has seen of Aurelien, if you live downstream of Prauge please look out for him in his blue canoe

    18:15, Thursday, 29 July UTC

    Marc Mutz

    Gpg4win v2.0.4 released

    Gpg4win LogoFrom the announcement:

    We are pleased to announce the availability of a new stable Gpg4win release: Version 2.0.4.

    The download is available via the usual download page:

    http://www.gpg4win.org/download.html

    This release contains a security fix for GPGSM.


    16:21, Thursday, 29 July UTC

    Jason A. Donenfeld (zx2c4/jdonenfeld)

    KRunner Dictionary Plugin: Finally

    Four months ago I promised to make a dictionary KRunner plugin. I’ve finally started to write it.

    It’s currently in kdereview and will hopefully be included with KDE SC 4.6.

    It functions as simply as I wanted it to back in March: you hit alt+f2, type “define {your word}”, and presto, the results are there.

    Unfortunately, it wasn’t as easy as it ought to have been. I utilize the same data source as the dictionary plasmoid, which is a Plasma::DataEngine, and as it turns out, DataEngine has a few issues with threading, which KRunner relies on. It’s also built around signal/slot async requests, while KRunner uses a blocking thread for computation. I ended up having to invoke a QMetaMethod to shuffle things to the right thread and use a QMutex for synchronization. What a hassle. Nevertheless, the dictionary plugin seems to work pretty well.

    Anything I should add to it? Ability to choose alternative trigger words to “define”? Some kind of loading indicator? If you have the time, try out the code and let me know what you think.

    Update: Some of you in the comments and on IRC have asked me the best way to try this out immediately. Here are the commands:

    svn co svn://anonsvn.kde.org/home/kde/trunk/kdereview/plasma/runners/dictionary dictionary-krunner
    cd dictionary-krunner
    cmake . -DCMAKE_INSTALL_PREFIX=/usr #change prefix accordingly if your distro is funky
    make
    sudo make install
    kbuildsycoca4
    kquitapp krunner
    krunner

    15:33, Thursday, 29 July UTC

    Michael Leupold (lemma)

    Bug Day Revival - Sunday 1st August 2010

    At this year's Akademy, in the back of the bus on the way to the day trip, several BugSquad members attended a spontaneous BoF meeting to discuss where we currently are and where we are going.

    During the last year we have had many active members who worked hard to bring order to our bugtracker. Often after a period of time, BugSquad members become involved in other parts of KDE - often coding in one of the various parts that need help. Gaining new contributors for KDE is good, but unfortunately BugSquad needs a constant influx of fresh blood to replenish our supply of members.

    This is why starting this weekend we'll be reviving our old habit of holding Bug Days. The purpose of a Bug Day is to help developers dig through large piles of bug reports, making it easier for important bugs to be found and get fixed. There are two flavors of Bug Day: one consists of investigating current bug reports to see if they can still be reproduced (so called triage) and the other tries to find new bugs in an application (krush). The scope of investigation is limited to one single KDE application per Bug Day, sometimes even only a specific part of an application.

    We're happy to announce that the target for our first Bug Day this year will be Dolphin. Starting this Sunday 1st of August around 10:00 AM everyone is invited to gather in our IRC channel #kde-bugs on FreeNode. The only thing needed to take part is an internet connection and a recent version of the KDE Software Compilation (the newer the better, if you need help equipping your system, be sure to stop by early). Senior members of BugSquad will be around to help newcomers get started.

    For information and coordination we will be using a page on the KDE Techbase wiki: http://techbase.kde.org/Contribute/Bugsquad/BugDays/DolphinDay1.

    14:45, Thursday, 29 July UTC

    Adriaan de Groot (adridg)

    Back in time (2)

    Different kind of back-in-time post, this time more like Marty McFly. I started Akregator (Kubuntu 10.4 installation) to reduce the amount of planet-surfing I do, and it comes up with a bunch of pre-configured feeds. One of them is Akregator News. It’s a fascinating time machine. I guess it’s in the default configuration and just never got changed, since it still points to the SourceForge pages. News articles about Qt 3.2, KDE 3.4 (remember that PIM skipped one minor then?). News stopped then and it moved to the blog, which culminated with KDE3-to-4 build instructions in december 2005. My. Have we been in KDE4-land (the long winding road to 4.0 and thereafter) for four and a half years already?

    10:29, Thursday, 29 July UTC

    Marc Mutz

    Sneak Preview: QList considered harmful

    We knew for a long time that QList is not a good default container, despite what the documentation claims. The problem boils down to the fact that for a lot of types T, QList<T> is needlessly inefficient by allocating elements on the heap and storing pointers to them instead of storing the elements in-place, like e.g. QVector does. Sometimes, for large and complex types, that might be exactly what you want, but a conservative estimate would put that chance at less than 5%.

    It never ceases to amaze me how people trained in the STL default to std::vector until a profiler tells them that they should use a std::list or std::deque instead, whereas people trained in Qt default to QList and not QVector.

    Effective Qt will soon come out with all the gory details, but since KDE’s 4.5 and Qt’s 4.7 releases are imminent, I decided to give you a sneak preview of just how widespread this inefficiency is. In order to do that, I finally sat down and developed a patch that emits a warning when you try to add something to an inefficient QList (at least if you set your compiler to warn for signed/unsigned integer comparison warnings). It’s been developed and tested with GCC 4.3 and Qt 4.6.3, but should work for a lot of other compilers, too. Please send me warning generators for your compiler in comments.

    The patch is binary-compatible, so you don’t have to recompile your Qt after applying it.

    Here’s a (incomplete) list of inefficient uses of QList (in the following, T and S are arbitrary type):

    • QVariant (!!) is too large.
    • QVector<T> isn’t marked as movable, even though it is.
    • QSharedPointer<T> is too large.
    • Virtually any QPair<T,S> is too large.
    • Enums not marked as movable.

    Run, don’t walk, and fix your new API to not use QList, or mark your new types as movable (details are in the patch). Alas, both changes are binary incompatible, so you can’t do them if you need your code to stay BC. This might be one of the reasons why QPair and QVector aren’t “fixed” yet: doing so would change the layout of the QList instantiated with them :( .

    But, at least for new code, there’s no excuse anymore: Just apply the patch.


    10:12, Thursday, 29 July UTC

    Ryan Rix (PhrkOnLsh)

    I wish I was a web developer sometimes….

    ….especially when I’m feeling masochistic. But, really, there are times when I wish that I could, or was motivated enough to learn, web and serverside development…

    I want project-integrated groupware in Fedora. Badly.

    Imagine Poelcat not having to send out reminders every month about what is upcoming in each Fedora subproject because it’s automatically added to a groupware calendar that’s exported to all the users in that FAS group automatically.

    Or the ability to not forget that damn FAmNA or Marketing meeting all the time, even though meeting reminders go out >.< because it’s automatically added to my groupware calendar with a reminder enabled in KOrganizer.

    Or a shared addressbook with details pulled from FAS in it…

    Task list pulled from a subproject’s Fedorahosted Trac instance….

    etc etc…

    I dunno if this is possible… The vast majority of it would probably be possible with some Zarafa plugins, but I’m not qualified or capable to write those, or even know how feasible they are… Maybe an FSC project for the next session?

    =-=-=-=-=
    Powered by Blogilo


    10:00, Thursday, 29 July UTC

    Sune Vuorela (pusling)

    Transport data easily to mobile phones

    I guess we all have the challenge of how to easily get a link or a phone number or some other strings of data from the computer to the mobile phone.

    With the help of mobile barcodes and klipper, this is now possible in KDE Trunk to do easily. Place some data in clipboard, click on klipper and select Show barcode.

    show barcode option in klipper menu

    Mobile barcode in klipper

    To read it, open the barcode app in your phone (mBarcode on n900 for example) and point it to your monitor.

    01:05, Thursday, 29 July UTC

    July 28, 2010

    Stephen Kelly (steveire)

    Grantlee version 0.1.4 now available

    The Grantlee community is pleased to announce the release of Grantlee version 0.1.4.

    This is the 3rd release of Grantlee in the month of July. Lets hope the development pace continues.

    Grantlee now compiles almost cleanly with QT_NO_CAST_FROM_ASCII and QT_NO_CAST_TO_ASCII. I say almost because I can’t actually build Grantlee with those flags by default without breaking binary compatibility, because of some interesting design decisions. Making it compile with those flags was a good learning experience though, and a step towards full localization support in Grantlee templates through multiple APIs.

    Another significant new feature in this release is that Grantlee now automatically finds its own default plugins at runtime. This is something I didn’t initially implement because I wrongly thought it was a platform issue to find plugins, even default plugins. Most new users of Grantlee hit into problems with this though, and finally Michael Jansen contributed a patch to resolve the issue. This should lower the barrier to entry to developing with Grantlee a little bit and that’s always a good thing.

    Michael is also doing some really cool type introspection stuff, so keep a look out for that. I think it could lead to performance improvements and increased flexibility in type handling.


    22:08, Wednesday, 28 July UTC

    Older blog entries