Lemma's blog

I recently developed (or rather redeveloped) a widget for entering times. It's basically a remake of the one you use in KOrganizer's "new event" window if you choose the starting or the ending time of an event (with a combobox-style popup to choose predefined times with a 15 minute range).

While writing such a widget there's a lot of things to consider, eg. how to check the input, which input formats to allow and what type of input to refuse. Just like the old widget the new one shows times in the time format you configured in your systemsettings. Additionally I made it accept times in plain 24h format (eg. 16:45) and military format (eg. 1645) as that's basically what the old widget already did.

Now as I live in a country where 24h format is regular, I have trouble understanding how users with a 12h time format enter times or rather what they'd expect the widget to do if they enter times. Luckily David Jarvie, the KAlarm developer, brought up the issue of "ambiguous" times, ie. times the widget could interpret in different ways. Now as I'm still unsure about how such inputs should be handled I'd like to get some 12h format user opinions on it.

What would you expect the widget to do, if you...

1. ... enter "12:25"
1. Accept the input and resolve it to "12:25 am"
2. Accept the input and resolve it to "12:25 pm"
3. Reject the input unless "am" or "pm" is appended
4. Something else (please describe)
2. ... enter "08:37"
1. Accept the input and resolve it to "08:37 am"
2. Accept the input and resolve it to "08:37 pm"
3. Reject the input unless "am" or "pm" is appended
4. Something else (please describe)
3. ... enter "1245"
1. Accept the input and resolve it to "12:45 am"
2. Accept the input and resolve it to "12:45 pm"
3. Reject the input unless "am" or "pm" is appended
4. Something else (please describe)
4. ... enter "0913"
1. Accept the input and resolve it to "09:13 am"
2. Accept the input and resolve it to "09:13 pm"
3. Reject the input unless "am" or "pm" is appended
4. Something else (please describe)

Please keep in mind that while I will consider your input thoroughly this shouldn't be understood as a "poll as to how it will be done".

I'm looking forward to hearing from you!

I've been working with DocBook XML content a lot lately and found it quite inconvenient that I had to transform it to HTML before being able to view it. As furthermore Konqueror (resp. KHTML) is still lacking support for embedded XSLT stylesheets, I started to poke at it. As a preliminary result I present you an XSLT plugin for Konqueror.

The mechanism is actually quite (mostly) simple:

• Check if the current document either has an <?xml-stylesheet?> directive or is of known type (currently only DocBook 5.0)
• Load the respective styles (and try to avoid Xml eXternal Entity vulnerabilities)
  
• Pipe the document through libxml and libxslt with libexslt (unfortunately QtXmlPatterns doesn't support everything needed by DB yet)
• Push the resulting file back into the KHTMLPart

Examples

This is what http://www.w3.org/Style/XSL/Overview.xml looks like with XSLT enabled (using the given <?xml-stylesheet?>):

Todo 

Unfortunately this is still just a prototype. It has several unresolved issues and is possibly INSECURE:

• Konqueror may crash on closing (it sometimes does for me)
• Level of integration is pretty low. You still see the raw XML content before it switches to the transformed HTML. I still have to figure out if this is suitable as a plugin, if I should create some XML KPart or if this should be integrated into KHTML
  
• No XInclude support
• Support for more XML schemata
  
• Possibly vulnerable to XXE (XML eXternal Entity) attacks which basically means a remote XSL could import a file on your harddrive

While coding I often have the need to create small sample-apps for debugging some library-code I'm writing or for figuring out what library code others have written does. Usually creating such a sample application not only involve creating and compiling some main.cpp as in a KDE context you also need some KAboutData, KComponentData as well as some basic CMakeLists.txt to actually be able to compile it.

While I could of course just construct some directories containing templates and just copy them to wherever I need it, I've lately been enjoying the power of KAppTemplate. This nifty little application uses pre-defined templates for various kinds of projects like KDE4 Applications, Qt4 Applications, Plasmoids and even PyKDE or KDERuby apps and a graphical assistant to get you going.

Now, I like doing stuff on the command-line and don't use all of the features KAppTemplate gives me (eg. filling the author or version part of the assistant is not needed of this particular use-case). So I decided to rip the template handling part of KAppTemplate to create my own little KAppTemplateCli to fit my needs.

Basic usage

Listing available templates

lemma@quechua:/tmp/tests$ kapptemplatecli --list
C++/KDE                                                     
  kapp4                - KDE 4 GUI Application
  plasmoid             - Plasma Applet Template
  runner               - Plasma Runner Template
  kpartapp             - KDE 4 KPart Application
  akonadiresource      - Akonadi Resource Template
  akonadiserializer    - Akonadi Serializer Template

C++/No GUI (CMake)
  cmake_plaincpp       - Simple CMake-based C++ application

C++/Qt (cmake)
  cmake_qt4core        - Qt4 CMake Core application
  cmake_qt4gui         - Qt4 CMake Gui application
  cmake_qt4core_qtest  - Qt4 CMake QTest Core application

[... stripped ...]

Showing template information

lemma@quechua:/tmp/tests$ kapptemplatecli --info=kapp4
Category   : C++/KDE
Basename   : kapp4
Name       : KDE 4 GUI Application
Description: KDE4 simple template based on CMake, inherits from XMLGuiWindow and demonstrates how to use KConfig XT

Creating an application from a template

lemma@quechua:/tmp/tests$ kapptemplatecli --template=kapp4 MyTest
lemma@quechua:/tmp/tests$ ls mytest
CMakeLists.txt  doc  icons  README  src
lemma@quechua:/tmp/tests$ mkdir mytest/build && cd mytest/build && cmake .. && make
lemma@quechua:/tmp/tests/mytest/build$ src/mytest

Download location & notes

• You can get KAppTemplateCli from: http://websvn.kde.org/trunk/playground/devtools/kapptemplatecli
• You'll need kdesdk and/or kdevplatform installed to get some templates it can use.
• KAppTemplateCli is not mature. Use at your own risk!
• It's not meant to be the same as legacy KAppTemplate by Kurt Granroth (which is command-line but takes an assistant-like approach like KAppTemplate)
  

Enjoy.

While testing some code that formats a time in the user's preferred format, I stumbled upon invalid formats in the Singaporean and Macanese time formats. Unfortunately I don't know the correct formats, so that's where I need your help. If you live in any of the 2 areas, please send me information on how times are usually formatted.

It would suffice if you send me the time "19:00" in local format and additionally specify:

• if your locale uses 24h or 12h (AM/PM) formatting
• whether times with a value for hour less than 10 are written with a leading zero (ie. "07:00" or "7:00").

After having hinted at it now and then, I can finally gladly announced that we (GNOME Keyring + KDE Wallet) managed to kick off a joint freedesktop.org project with the goal of creating a common infrastructure (or more technically: protocol) for managing passwords and other secret values.

I expect several benefits for our users:

• They will be able to securely store their secrets. Even if they use a mix of different applications (GNOME, KDE even plain Qt) they will only have one background service to authenticate to.
• They will be able to switch your browser without having to reenter your passwords if the browser supports the API - unfortunately no word from Mozilla if they're interested.

If you're an application developer, don't worry. While I expect a new client-side API (which I imagine to be more OO style than KWallet::Wallet), I'll keep an eye on providing something the current class can wrap so even applications using the old API will be able to use the new system.

In case you're interested in joining the drafting process, you can find the current working draft as well as more information inside the freedesktop wiki.