Gustavo Sverzut Barbieri

This semester I’m coursing Computer Graphics, a great computer science topic!

So far we have coded basic 2D operations, like lines, circles, polygons and ellipses and voxel visualization with clipping planes.

As I have noticed few documents and code on the web, I plan to write some articles on this topic later, right now you can access the code at:

SVN repository: http://basiccomputergraphics.googlecode.com/svn/

This week, while finishing my Computer Graphics assignment I had to deal with a library my professor had “sponsored” the development: libgip.

This library have a great purpose: easy development and maintance of GUI (Graphical User Interfaces) of Computer Graphics & Image Processing software. These software generally have some toolboxes, user input components and the canvas, where output is shown. After he experienced with TCL/Tk and Gtk for some time, he experienced some problems, the slowness of the former and the big API (Application Program Interface) change from Gtk1 to Gtk2. So he opted to code an abstraction layer atop of a toolkit (he have chosen wxWidgets for some reasons), so if the underline toolkit API changed, one port this layer to the new API and every program based on it should work.

Ok, a great idea, sure, but how about the code?

Well… to begin with, there is no source code available and no documentation. I had to read include (.h) files, which were poorly documented and not all prototypes were implemented, not even some basic widgets, like spin buttons or table layout. Then I reached some weird limitations, like the maximum of 4 buttons per application and then some weird bugs, like one in gip_check_box_get(), which receives the widget as first parameter, but actually uses the last created widget! What the hell? I cannot check the code, but it seems that the whole thing uses global variables (reentrant code? “what is this?” the code author’s may think)

If this library wants to reach any usable state, it should be rewritten, by someone that can code properly in C and with the following requirements in mind:

1. Provide high level components to request user input, something that, given a label and possible some limits (based on type), assembles an uniform and pretty user interface. Something like Label-Entry, that adds a label and a text entry, in a tabular layout, or Label-Degree, the same, but with a specialized widget that limit user input to valid degrees, possible with limits like 0-360°, Label-Color (to pick colors), Label-Histogram (to present histograms), Label-Range (to select start and end values), other like Label-Float, Label-Integer, both with optional limits, increase steps and callbacks if data changed. If this layer wants to easy users lives, this is the first step.
2. Use widgets names and avoid widgets as global variables. Almost every GUI toolkit provides way to refer to a widget by its name, so you don’t have to keep a global variable pointing to it, this make things much easier.
3. Use garbage collector or an intelligent memory management system. With today computers, there is no advantage to do memory management by means of malloc() and free(), they make you code a lot more and most bugs comes from it. GCC uses the garbage collector called boehm-gc, Samba uses an intelligent memory management system called talloc, it takes care of memory using a a hierarchical, reference counted memory pool system with destructors, it can release a whole tree of allocated memory with just one talloc_free(). Using one of these systems will reduce code, while improve software quality and stability.
4. Easy to use GUI description. Probably the best way to address it is with a run-time interpreted file, something like XML or other text format, so developers can change and test their GUI without the need to recompile the whole software, a process that often takes some time. Callbacks and controller code can use widget names to operate on them.
5. Easy to use data saving/loading system. Often programs need to store user settings and programmer should not have to code it again and again. This should be easy, probably associated with GUI description mentioned above, data could be marked as “persistent” and it would be loaded/restored automatically.
6. Threaded design with automatic locking handling (whenever possible): computer graphics and image processing are too CPU intensive and may “freeze” GUI for long time, giving users no feedback may lead them to kill the application. With an easy to use thread system, users may delegate CPU hungry tasks to a thread, leaving GUI responsive.

Voice over Internet Protocol (VoIP) is one of the greatest thing I know, no more pay per minutes of use, call everyone, every time, everywhere!

However Open Source VoIP software have major drawbacks, some have a weird Graphical User Interface (GUI), some try to do everything from scratch, some are unstable… That really piss me off!

As a KDE user, I have no integrated software that is able to use my VoIP provider, stanaphone. KPhone is horrible, KCall tries to be better, but since it uses KPhone stack, it doesn’t work right, so I have to use LinPhone, a project that have a really weird GTK2/Gnome GUI. And I lost everything KDE provides me.

For those unaware of KDE features, you can have remote resources for Address Book and like, they can be everything, you can store your address book on a IMAP folder or using SSH, so my home, work and other computers all share the same address book, agenda and notes! Wonderful. Also, my instant messenger (kopete) uses the Address Book resource, everything integrated, wonderful!

KCall uses this feature and instead of creating an address book from scratch, you can edit contacts using KAddressBook and they’ll show up, a great plus. But it’s poor implementation bugs me while using remote resources. Also, it use KPhone SIP stack, which sucks. Another thing is that it doesn’t cooperate with Arts, the KDE sound server.

A week or so I read about Tapioca-VoIP, developed by a Nokia sponsored research team, it uses Nokia’s Open Source SIP stack called Sofia-SIP and GStreamer to handle encoding/decoding sound and output it to sound card or sound server. Altough not ready yet, it seems much more promising, since it have a narrow focus, skilled people and funding.

So I think: “KDE infrastructure + Tapioca-VoIP = 99% of a KDE integrated VoIP”, yes it is! And I think I can code the other 1%, so I have started.

So far I have opted to use the QT/KDE dock utility, as used in KDevelop, Gwenview, KOffice and others. With it you can have a widget that can be re-arranged as user wants, hidden or detached. I don’t like the tab-arrangement commercial phones are using, but it can be an alternative layout.

I have also created a small, but important, widget: AddresseeSelector. It’s like KABC::AddresseeDialog, but it’s more powerfull and customized, I hope it get included in KDE. I’ll request it as soon as I have something more stable and optimized. This widget have a search bar to filter the list view that features contact’s information. I have tried to put there most relevant information, like Picture, Name, Phones and Addresses. The latter are split into some columns: Phones (every phone), Mobile Phones, Work Phones, Home Phones, Work Faxes, Home Faxes, Addresses (every address), Home Addresses and Work Addresses. Users will be able to hide some columns and this will use KConfig to save this preference for your application.

So far you can grab AddresseeSelector at http://tux08.ltc.ic.unicamp.br/~gustavo/addresseeselector/.
KDE Bug Report: #115706.

Ideas?

Hey,

I don’t like blogs at all, but let’s see how active I can keep this!