Second comming of kaddressamba

Yey!

Someone else decided to work on this concept and actually wrote a SuperKaramba based applet

More info to follow.

Sabbatical

Like all normal people, (and I hope I am within one standard deviation of some "normal") I have to reassess my priorities on a constant basis. I have to think about the usefulness of this project for me and, quite impornant, for the general public.

This applet is concieved as a solution to a specific problem - a problem that suddenly seems less and less accute:

1. I must write a stream-ripper for MPEG2-capable /dev/video0 of my TV card. None of the solutions I found work or fit me. The current way of "cat /dev/video0 > file" cannot schedule an automatic stop, or, multiply the channel for simultaneous rec / view. I fall asleep and find my HD completely out of space in the morning. I must fix this situation first.

2. I am tracking the progress of both kio-clucene and kat. My hope is that they'll be able to index the kaddressbook themselves. Then, the whole community will just write a good matter-agnistic search front-ends for them. Seeing Kat support clucene db in latest beta - I think this is chugging along just fine towards being a better solution to the original problem and kaddressamba's reason to exist.

3. SuperKaramba is Python-based and has specific API. Plasma will be (initially) JavaScript-based and who knows what API it will have. Coding something that is cool but "redundant" and old-on-arrival makes this yet less appealing for me.

The bullet points don't make the project dead, but, rather, unimportant in the grand scheme of things. Thus, it will lie "GUI-less" for a while.

Progress so far

DONE:

1. The backend python script is done. It takes relevant kaddressbook data, puts it into an array (errr... python's list variable) and sorts it. Keyword-based searching is implemented and gives output to stdout.

2. The search entry field SuperKaramba applet works. It looks exactly like the (upper) module in the sketch bellow. The UI is not a final decision, but it'll get me where I want it to be.

WORKING ON NOW:
I was looking at Contactlistas an example of dynamic list, but found it unflexible for my purposes. Looked at TooDooList and found what I was looking for - ingenious list creation\destruction engine.

item = [bgrnd, btn1, text, text2, text3]
items.append(item)

where bgrnd, btn1, text, text2, text3 are pointers to objects created earlier in the loop. I was looking for examples of creating 2 dimmentional arrays in Python; and this one by far is the smoothest.

Looked at a search example SuperKaramba applet, and realized that if there will be a multitude of search applets for files, addressbooks, dictionary words, etc, then we'll have too many search fields on the desktops. Better have one, and use Up / Down mouse wheel buttons to choose the search function. One universal search field, with search-engine plugins... Hmm... will think about this later.

Inspiring SuperKaramb-oids

In my "pillage the code" swing by the kde-look.org's Karamba section I ran across some awe-inspiring pieces:

WheelLauncher

Neat scroll-wheel launcher. Very ingenious visually. Simple, intuitive, very effective. Cool! (Yes, Ryan, I did see iLauncher. :) )

ContactList
A Kopete "assistant" that tries to (almost) dublicate all basic features of Kopete.
The neatness is in its clean organization & user-friendly theme-ability.

My pillaging is not over yet. Will add more "neat" things later.

First Sketch

(sketch)

SOME EXPLANATION:
- NO "click to new email"-like functions will be implemented at first. The main focus here is to make "search'n'display" stable and functional. However, as a go-around I intend to make the contact blobs clickable so they can open the entry in the Kaddressbook. Same goes for the "Book" icon on top.
- I hope the "book" icon will be dynamically (automatically) adjustable based on your current icon theme. This way I can avoid the "can you make a Nuovola style..." bs. One of the reasons behind the austere UI is my focus on functionality and universalism, not on cool look.

NOTES:
- Didn't come up with idea of how to close the "results" list yet. May be will use the "clear field" icon in inputBox to do both, clear input and results.

And on we go...

"Лёд тронулся, господа присяжные заседатели!"
"The ice is melting, laddies and genlemen of the jury!" (roughly translated from Russian)

After a swift (rude?) intervention (by yours trully) into an otherwise peacefull, almost uneventfull life of one KDE developer the show-stopping bug with the Unicode-ness of inputBox appears to be fixed.

I have little intention (translation: scared of) trying to install KDE 3.5 SVN snapshot to test the fix, so, will just assume it is fixed and go on.

On to GUI design design we go. I had some preconcieved ideas about UI, but apathy creeps in and now I am much more conservative in my outlook. Will post a (hand drawn) mock by the end the weekend (Nov 5-6).

The Intent

What is it?

It is (going to be) a Kaddressbook applet for SuperKaramba.

Why not before?

Wanted to do a Kaddressbook SuperKaramba applet for a loooooong time. For all this time 2 crucial pieces of the puzzle were not awailable: a) text entry fileld was not supported and b) there was no easy way to get kaddressbook data into Python (the language of SuperKaramba).
Finally, a) is taken care of with SuperKaramba ver. 0.37 (As of Sept 9, 05 still in beta), and b) was addressed by a command-line client for kaddressbook called Kabc Client.

What will it look like?

In default mode it will be very small - just an indicator and a search field.

In full listing view mode a box will be added to (drawn out of the...) search field. This box will contain Given Name, Family Name, phone, email address and, possibly other configurable fields.

Search results view is exactle the same box as in full view but only with matched contacts showing.

Detail view will be used for showing of contact's complete vCard.

All of the views will have minimal decorations to achieve 2 things: effectivenes of presentation through high signal-to-noise ratio, and visual acceptedness for all artistic tastes.

How will it work?

Python script calls kabcclient with a "-list" option to get all the contacts' data* in the kaddressbook into a CSV (well, actuall, tab-separated-values) formatted Python list variable. That bacomes the "master" address book for the applet.

* Data consists of:
1. Given Name,
2. Family Name,
3. Nickname,
4. Other Name (middle name)
5. email address(es)
6. phone numbers.

All of the fields are searcheable at once.

I have no immediate plans for "cool" features like "email to, or call to contact," limiting the range of the search by addressbok type/class, or other fancyness. What I need to achieve 1st is base functionality.

Misc thoughts:

- No, it is not a "clone" of address book applet from Mac. I have never seen it in action. (I did see a screenie of it as part of some Apple promotion, and was not impressed by the look of it) My inspiration for this applet is KickPim - a KDE panel applet with excelent all-around features. Unfortunately the developement of KickPim froze and I don't know C++ to pick it up. Kaddressamba is my attempt to pick up where KickPim left off.

- Why not use Kabcclient's "-search" facility and avoid "doubling up" with internal address book? - File access. It happens every time I do a query. Avoiding that is my primary reasoning for keeping all the relevant address book entries in internal database.

- I know that this app will be useless as soon, as Beagle, or Clucene learn to search and present address book entries.

BTW: gluecene, clueseen, etc. it took me a google search to recall how a this kewl desktop search tool for linux is called. What a HORRIBLE name for convenience tool! Pah-leeeez!!!! rename the kio-clucene to something more meaningful so I can finally get around to using it!

"Do I know you from somewhere?"

Unlikely. My other toys of relevance (Centurion clock theme for StyleClock and Fusarama applet for SuperKaramba) were only of limited use.