Wanted: developers/users of phone programs

Do you use or develop a program to phone right from your computer? Then I want your help. By answering these questions:

• What is your program?
• How can I control your program from another process? E.g. start a call, get signalled about an incoming call, accept the incoming call, close a call, etc.? Can I do so by DCOP, DBus, or something else?
• Does the program use the KDE addressbook to store the numbers?
• What kind of numbers are there for the different phone systems? What format do the numbers use?
• Can you do conference calls?
• Would you like to help writing some plugins to support your program?

I ask because I want to create new or improve the existing phoning plugins for the Contacts framework. For KDE 4 such things might best to be done within Kopete, Decibel, Tapioca & Co., but for KDE 3 I want to support this by service plugins in the before mentioned framework.

So one can click on a number on a Contact card and have the action service signal the phone program to start a call. Or do this from the action menu of a contact button in the Contacts applet for Kicker.

For Instant messaging Will Stephenson wrote the general framework KIMProxy, which does all the work, so writing plugins for this was simple. For phoning nothing like this exists, and as I don’t phone right from the computer right now, I cannot test myself. But I would like to see what interaction models there are, so I can extend the Contacts framework to fit.

And BTW: Yesterday I uploaded a new mini release of the Contacts stuff to kde-apps.org. The framework code, the applet and the card server are now splitted into three different packages. And the applet features support for actions on lists of contacts, like emailing or sending a file (currently only available if all contacts have the property needed, e.g. an email address). So get it while it’s hot!

Looking for Troubles: From One to Many

I just wanted to add support for services on whole list of contacts to the contacts framework. Looked pretty easy, as all the structures and algorithms were already done for single contacts and should just be a Copy,Paste&Adapt job.

Of course, things were/are not that easy. I have found some questions:
Should a service be only shown if it supports all of the contacts in a list, or also if only some of them are? Make it configurable? Per usage, e.g. button? If one selects the service “Email to…” she might expect to be writing to all in the list, not?

And if a property has several variants, like email addresses, is it okay to always use the default variant? For single contacts by now an action is added for every variant, but for several contacts is would be pretty useless to add an entry for every combination of variants, I guess.

And I wonder which services should support lists of contacts. Would e.g. one want to have all the cards of a list of contacts appear together? If some want, should this be configurable for each contact list appearance? And for each service?

I gave myself some answers. But they tend to result in inconsistent treatment of single contacts and whole lists of contacts. Not perfect.

Another thing that makes me currently not too pleased is ending with class names like ListAllPropertiesDefaultDataActionServiceMenuFiller. I do wonder if I have lost my track. But each term inside the name is needed to differ the class from similiar ones:

• List, because there is a menu filler for single contacts
• AllProperties, because there are menus for only one property
• Default, because this limits the shown services to only some (so things like “Copy address” are optionally left out)
• DataAction, as it’s about actions for given data (e.g. by Drag’n'Drop)
• Service, could be left out, but makes basic class ambigous
• Menu, because there also fillers of buttons
• Filler, because that is what it does

The class is the one putting the actions into the menu which appears on a drop on a list button. It also cares to execute the service of the chosen menu entry, and updates menu entries if a service signals a change in it’s availability, given it works in a dynamic system (like instant messaging):

I hacked it now to an end, so it just works. And finally it takes me only two clicks to begin an email to a whole groups of people from Kicker
But the list support really needs another thought. Looks, like I found something new to do when sitting in the train to and back from the family…

Dumped Contacts framework as 0.1.1

Just declared the current code of the framework for contacts and their properties in KDE’s repository to be of version 0.1.01* and dropped a tarball at kde-look.org to use with KDE 3.5.

* You only release to find bugs…

The TODO list may be still quite long, but the framework and the two applications, a kicker applet and a contact card server, are already pretty usable in their current form. I should know because they are part of my daily workflows. No bugs known, no crashes for me. And with the configuration editor for contact list buttons of the applet I added today the last hurdle for a use by Joe User was removed:

Should prepare a move out of playground. No idea if the target should be extragear or perhaps kde-pim for a possible 3.5.7 release. If I went for kde-pim the code could be even merged into KAddressbook. That would be cool. But will there be a 3.5.7 release? And when?

For now I will try to make a good official release directly out of playground. Have to read up how to do so, and then ask the translators to help me by localizing the strings So 0.1.2 should end on quite some more desktops.

Once that is done, Okteta will get my attention again. But for now I need to push that contacts framework into the world, to get some feedback. After all I would like to get a successor (named Organs) into KDE 4, and that should kick even more asses