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