For Kate we have a cia.vc IRC bot posting stuff like this when new Kate related content is commited:

[00:18:29] <cia-20> ehamberg * r874179 [..]/katevikeysequenceparser.cpp
[00:18:29] <cia-20> fix crash when a qkeyevent's text() is empty
[00:18:29] <cia-20> http://websvn.kde.org/?view=rev&revision=874179

As cia.vc seems to attribute all KDE commits to project "KDE" and not its actual children (i.e. "Kate" in our case) and because getting the above n-liner with Websvn link is not completely trivial so I thought I blog about it and show our current "Advanced Filtering" code here:

<and>
 <or>
  <match path="project">Kate</match>
  <match path="project">KDE</match>
 </or>
 <or>
  <find path="files">KDE/kdesdk/kate</find>
  <find path="files">KDE/kdelibs/kate</find>
  <find path="files">KDE/kdesdk/doc/kate</find>
  <find path="files">KDE/kdelibs/interfaces/ktexteditor</find>
 </or>
</and>
>  
<formatter medium="irc">
 <format appliesTo="CommitToIRC">
  <autoHide>
   <color fg='green'><author/></color>
  </autoHide>
  <autoHide>
   <color fg='orange'><branch/></color>
  </autoHide>
  *
  <autoHide>
   r<b><revision/></b>
  </autoHide>
  <files/>
  <br/><log/>
  <autoHide>
   <br/>http://websvn.kde.org/?view=rev&amp;revision=<revision/>
  </autoHide>
 </format>
</formatter>

I'm very happy to see that cia.cv

• provides such a service
• has online validation of the filter code so you won't save a broken filter
• has invented such a nice XML format

Well done guys, I'm impressed.

Yes! Old hardware:

• Intel Pentium 4, 1.6GHz, 512KB Cache, 1GB RAM

New hardware:

• Intel Core 2 Duo, 3.0GHz, 6MB Cache, 4GB RAM

The compile times for GCC 4.3.1:

$ genlop -t gcc
* sys-devel/gcc
[..]
Fri Sep 12 03:07:40 2008 >>> sys-devel/gcc-4.3.1-r1
merge time: 2 hours, 33 minutes and 15 seconds.

Fri Oct 10 01:02:54 2008 >>> sys-devel/gcc-4.3.1-r1
merge time: 37 minutes and 53 seconds.

.., as I learned today, seems to be understood as a two-part process by providers: one half is moving the number away from your old provider, the other is moving it to the new provider. While I've seen charges for moving a number to a provider, charging for moving it away came as shock for me today. And it's expensive like hell, holy sh..... cow. So I started looking around to see if this might be something separating good and evil providers but it doesn't look like that to me so far. Here is what I collected:

Maybe I can find out why they all charge about the same.

v3, now status quo

The "Add..." buttons

.. are not gone - they went into the line edit's context menu.

The search mode

.. can now be switched using the shortcuts from Alt+1 to Alt+4. No more Tab- Tab-Tab and no more need to click.

Selection only

.. is inside Options, though several people wanted direct access. I'd say try to work with it for some time and if it's a real pain we will have to find another solution later. Okay? I should mention that one tiny bit of this is still missing: The plan is to re-initialize Selection only when the user changes selection in the document. I expect this to come in the next few days, stay tuned. [EDIT 2008-10-13]: Just arrived with revision 970640.

Use placeholders

.. has been removed as an option. It internally enabled when replacing text in Regular Expression or Escape Sequences mode. I hope this is working for you, not against you.

For some it might be old coffee, maybe not for everybody. I just stumbled over the free download of the first edition of ..

C++ GUI Programming with Qt 4 The second edition is in stores currently.

v3, a new candidate

I have been talking to people, read written feedback and put both in the new mockup. Like last time, below I will try to explain what drove which changes. If I get green from the main KatePart devs I'll go for implementing this.

Selection only

.. is still not there, though requested. Let me explain. In KDE3's KatePart the checkbox called "Selected text" is initialized when the dialog opens as following:

1. If multi-line text is selected it's checked
2. If single-line text is selected it's not checked
3. If no text is selected it's not checked

So actually toggling the checkbox means that you want to do one of these two things:

1. Searching the whole document for something spanning several lines
2. Searching for text within a single-line selection

I assume both to be "rare" cases. For now I'd like to put Selection only into the Options combo and see how it works in action.

The mode combo box

.. aligns with the line edits now so they share the same vertical scan line when the dialog is shown at minimal width. As we have one button less in v3 than v2, we have more space to do stuff like that. Still, v3 is less wide than v2.

Highlight all

.. will probably not change too often. It's current state can often be told from looking at the document. Therefore it's moved into the Options combo box.

The "Find:" label

.. is right aligned now as requested.

v1 / status quo

v2?

Hello! What's this? It's the current state and a new draft for a possibly next version of the power search and replace bar in KDE4's KatePart, and therefore Kate and KWrite and more. The current approach has several issues. To address some of them I have been doing two things recently:

1. Starting a wiki page collecting issues , ideas , feedback. Your participation is very welcome. Tell us what we don't know.
2. Creating a new mockup dialog (above) addressing some of the current issues

First: If you have comments to share please add them to the KatePart Search Bar wiki page or write a mail to kwrite- devel@kde.org, thank you. Below I will try to explain some of the ideas behind the above screenshot. Not all are mine, especially similarity to Jens Bache-Wiig's earlier mockup is not by accident. To sum up the benefits I personally see in this new draft are:

• Less width
• Less height
• Less complexity
• More friendliness

Why this way?

The "Add..." buttons

.. are gone for space and relevance reasons. If they are missed by people we can still put this feature in the edit lines' context menu later. Also they are hard to integrate into a layout.

Search mode, Match case and Highlight all

.. are what I consider the minimum set of options that need to be visible and accessible as quick as possible. That's why they are represented by their own controls here.

Any other boolean options

.. go into the Options combo box, e.g. From Cursor and Selection only. The latter is a good example of a setting, that the bar guesses correctly in most cases, so people don't need to change it often. At the same time the Options combo box can be extended with as many checkboxes as users turn out to really need, whatever it may be.

The mode combo box

.. shows the text "Plain Text (Alt+1)" currently. The idea is to assign free default hotkeys to all four modes so switching using the keyboard is efficient. The shortcut itself is shown so the user starts remembering it and save reading manuals for easy things. Before that to switch from Plain Text to Regular Expression mode you would have hit Tab , R , Shift-Tab (or Ctrl+R again).

The Next button

.. is left of Previous to be closer to the search pattern line edit which aims at reducing the way you travel with your mouse, as Next is probably hit much more often than Previous. Nothing new but I still found it worth mentioning as it feels unintuitive to many at first.

Highlight all

.. is not a checkbox anymore because I felt that it's very different from stuf like Match case semantically. "Different things should look different" — I forgot who said that.

The "Find:" label

.. is aligned left now. Somehow right-aligned felt unnatural to several people, now me included. [EDIT] I changed my mind - I prefer right-aligned now.

The Use Placeholders option

.. will either go into the Options combo box or change with the search mode. I currently tend to the latter as it seems I never missed it in any other editor before though I regularly switch between Plain Text, Escape Sequences and Regular Expressions.

Last words

Again, please participate in improving the search bar: Extend the KatePart Search Bar wiki page or write a mail to kwrite-devel@kde.org. Thank you!

PS: If all this doesn't make any sense - it's 4:41 on my clock... ;-)

Besides bug fixes and cleanups this release mainly features a re-designed XSPF writing API and malicious XML detection à la billion laughs. The writing API in previous releases was unnecessary ugly; I think it got better. Malicious XML detection should be of most interest to people using libSpiff in web services. More about its internals and configuration can be found in the API documentation. Please note this release is neither source- nor binary- compatible to previous releases (including 1.0.0rc3).

• Download
• Changelog

This release now fully implements the error model introduced in libSpiff 1.0.0rc1. libSpiff has been a very strict parser from the beginning - too strict for real world XSPF files. In a recent test on about 650 XSPF files from the net only 47% held valid XSPF content. With previous releases of libSpiff this was the exact percentage you could have read. With libSpiff 1.0.0rc3's support for error skipping you can now read 73% of these very files, mainly leaving only files with errors on XML level out. Still, when needed, libSpiff can act as a validator as strict as before. I'll be happy to answer any questions about these changes. Please note this release is neither source- nor binary- compatible.

• Download
• Changelog

I've been batch-checking the first 661 XSPF files that Google gives you when searching for filetype:xspf. As Murphy would have expected every error that could occur actually did. An interesting pattern is that

• 47% of the checked XSPF files are invalid
• 58% of these because of XML errors

That's shocking but I expected worse. As an XML parser is not allowed to ignore errors, there is no room to do so for an XSPF parser. Even big players like Magnatune have hit invalid XML below XSPF in the past (but took the time to fix it). Getting XML emission right - especially escaping what needs to be escaped - is the most important step on the way to valid XSPF. From the error distribution in today's test set I can tell these are the four most important steps you have to take with importance descending:

1. Get your XML right, escape what's needed
2. Get the XSPF namespace right, it's http://xspf.org/ns/0/ _with 0 for XSPF-1!
3. Keep your URIs valid, they need loving too
4. Wrap your own tags inside an <extension> element (or <meta> for simple stuff)

XSPF users around the globe will thank you for that. Have a valid night everyone. ;-)