Hari's Corner

This is yet another simple HOWTO for personal reference, but I document this in the hope that it will be useful for others as well.

As I mentioned before, the gtk.TreeView widget is one of the most tortuous Gtk widgets ever created. Using and manipulating it involves quite a few non-obvious techniques. Here's the code to deleting multiple selected items in a gtk.TreeView widget.

In the below example the widgets are created by Glade/GtkBuilder so I call the get_object () method of the GtkBuilder object to get the widgets.

def remove_selected_items (self):
	# get the file treeview and liststore
	file_view = self.ui.get_object ("tree_files")
	file_list = self.ui.get_object ("filelist")
	# get the selected rows as paths
	sel_model, sel_rows = file_view.get_selection ().get_selected_rows ()
	# store the treeiters from paths
	iters = []
	for row in sel_rows:
		iters.append ( file_list.get_iter (row) )
	# remove the rows (treeiters)
	for i in iters:
		if i is not None:
			file_list.remove (i)

As you can see, it involves the following steps:

1. Get the TreeSelection object associated with the TreeView and call get_selected_rows () to get the row model and selected paths.
2. Convert each of the selected paths into TreeIters.
3. Now call the method remove () method on each of the selected items in the ListStore or TreeModel object.

Note that directly trying to remove paths in the first step will lead to an error because once a path is deleted, the remaining paths might point to a non-existent node.

This is more for personal reference after struggling for half an hour with Python and Glade/GtkBuilder to figure out how to add a gtk.CellRenderer to a gtk.TreeViewColumn for a tree view that was created in Glade.

The steps are not obvious because most of the tutorials out there are for pure GTK code and assumes all the objects are created programmatically and not from the GtkBuilder XML file.

Simply the steps are:

• Add a column to the TreeView in Glade. This is done by editing the treeview not the tree model object. Right click on the tree view object and click on Edit... in the context menu. Then add a column from the Hierarchy tab.
• Now associate a ListStore or any other tree model with the tree view. This can be done either in Glade or programmatically. Take your pick. I prefer to do it in Glade because you can create columns for the tree model as well.
• Now in the Glade program add a cell renderer to the column and associate it with the column number in the model as follows. Place something like the following piece of code somewhere in your initialization code (obviously the variable names/attributes will have to change

# Get the TreeViewColumn object associated with the tree view - self.ui is a gtk.Builder object
# in this case the index is 0
col = self.ui.get_object ("tree_view").get_column (0)
# Create a text cell renderer
cell = gtk.CellRendererText ()
# Add the cell renderer to the TreeViewColumn
col.pack_start (cell)
# Attributes for the column - make it display text of column 0
# from the model
col.add_attribute (cell, "text", 0)

It's all a bit confusing and irritating to have to deal with all this and I personally think that GTK's treeview control is a royal pain in the rear for programmers, especially when used in conjunction with Glade.

Half the stuff is done in the Glade interface and the rest programmatically. This is a mess and should be a high priority for the GTK programmers to rectify: either improve Glade or simplify gtk.TreeView.

This topic occurred to me after idly observing a few talent show programmes on television. The judges on these kinds of programmes vary a lot, but I find that they fall into two major categories: the ones who are "brutally honest" and pride themselves on constructive and honest criticism and the ones who bestow empty unwarranted praise regardless of merit because it's the easier and pleasanter option. Both kinds have problems. The issue with undeserved praise and flattery is rather more straightforward. But when it comes down to "constructive criticism", I think it generally fails on rather more subtle grounds.

As a concept, I think the whole idea of constructive criticism has a few flaws. I personally have no problem with the idea behind criticism - even biased criticism - so long as it is undisguised and the intent of the critic is open and transparent. It is constructive criticism that often causes problems - in either tone, content, intent or a combination of the three.

As a whole, I think it's a rather touchy area for people who are at the receiving end. Constructive criticism, in theory, should be taken for what it is: an analytical study of a subject's merits and demerits and suggestions for improvement. In practice, I find constructive criticism often more negative than positive. There is always a tendency to over-analyze and nitpick. This shouldn't technically be a problem when the overall tone is positive. However, I think the result is often that the person receiving the criticism can end up getting hurt or upset. The problem here is that the recipient is expected to take it entirely in the positive sense and as a stepping stone to improvement. Purely logical beings would no doubt find it the obvious reaction. However, as human beings, we are emotional. We don't like flaws pointed out. At least not all the time. Sometimes we become defensive unconsciously. It can also have an overall demoralizing effect on the psyche. When somebody points out ten negatives and two positives, the negatives overwhelmingly stand out even if the positives are emphasized.

I attribute it to the fact that while we all want praise or appreciation but somehow develop a distrust for it. Anything positive is taken as "being nice" while negativity is evaluated as "brutal honesty." Nobody starts a positive commentary with the phrase "I'll be brutally honest with you" or "To be frank". The human mind naturally associates this with negativity and passes judgement. As a result, even the positive aspects of constructive criticism tend to get played down or written off as a lazy attempt at balance. More generally, critics tend to analyze failure far more deeply than success. If you read book or movie reviews, negative reviews often tend to be longer. Ever wondered why?

This kind of analysis can be even more unhelpful than unwarranted praise because it can destroy confidence in sensitive individuals; all the more for being perceived to be "constructive" and "honest".

So is it that positive commentary can never be taken as honesty? I don't think so. There are ways to do it effectively. So long as there are cogent and good reasons for positive criticism, I think it can be enormously satisfying as well. We all require praise or appreciation, but sometimes a little more than that. Constructive criticism has to be equally objective and analytical about positive points as well. Otherwise it tends to lean more on the negative side. Criticism, whether analytical or biased has to have one main quantity: balance. And that's all there is to it.

I'm currently writing a simple growisofs wrapper in Python/Gtk called BiaDVDBurn. growisofs is part of the dvd+rw-tools commonly packaged in most Linux distributions.

The main reason I wrote this is because I often find a lot of GUI front-ends trying to be too intelligent and sometimes failing in the process when the backend tools do the job when invoked from the command line directly.

I've not yet uploaded it yet, because there are a few things I want to tweak before doing so. Uploaded now. Check the software page for more details and screenshot.

I've decided to finally call it a day as far as FreeBSD is concerned. While I really like the base system and the FreeBSD approach to system configuration, the biggest drawback in my book is the ports system.

For those unfamiliar with ports, reading the Wikipedia page would be handy from this point onward.

Now the majority of people in the BSD world swear by ports. Indeed reading on online forums, I got the impression that the ports system is why people choose FreeBSD over Linux. In many of the cases, I get the distinct impression that these people haven't really considered the real benefits of a thoroughly tested and workable binary package management system like Debian. I don't want to get into the debate over which is better: compiling from source or using binary pre-compiled software. All I can say is that I hate to waste my time waiting endlessly for software to compile. My experiences with Gentoo in the past have taught me that it's near impossible to keep a source-only distribution updated frequently without sacrificing a huge chunk of your productive time.

You see, in FreeBSD there are two methods of installing software: ports and pre-compiled packages. The problem with people who don't want to compile everything starts with the fact that the majority of FreeBSD software management tools are focussed and optimized towards ports. There are packages available, but they are never updated after they make it into a -RELEASE build. The -STABLE branch usually has updated binary packages but they are still behind in version compared to the ports. Another issue is that many (useful) ports don't make it into the package tree. All these aspects makes it an exercise in frustration for people who don't want to spend half their computer uptime compiling software from source.

The real issue with ports, in my view

The real issue with ports is that if you have a system that you want to keep updated with the latest versions of software, you have no choice but to use the ports tree and compile everything exclusively from source.

It's rather difficult and even unrecommended by FreeBSD users themselves to mix binary packages and ports in the same installation for the simple reason that package and ports dependencies vary and that trying to keep packages/ports mixed system up-to-date with only binary packages from the -STABLE branch is a clunky process prone to dependency errors which might arise from a package depending on a newer version the software only available as a port. This already happened to me a few times when I realized that if you want to use FreeBSD on a full-featured desktop system you are forced to use ports almost exclusively.

If there were better binary package management tools in FreeBSD and more up-to-date and comprehensive list of packages in -RELEASE or -STABLE, I would have no problems.

Finally for those who prefer NOT to be on the bleeding edge, ports is a constantly moving target. It's a "rolling" system that is kept updated by the FreeBSD community and is not dependent on any particular release of FreeBSD. While always using the latest and greatest has its advantages, it is to be realized that they are not as thoroughly tested as binary packages and can lead to problems when used with older releases of the FreeBSD base system.

The purpose of this article

I'm not out to bash FreeBSD or its philosophies here. I just enumerated reasons why I personally don't prefer its software handling mechanisms. I also would like to let other Linux users know the potential pitfalls you can face when you switch from one OS to another.

If you are a FreeBSD user and have any constructive suggestions do post a comment!

Continuing from my previous entry, it's been a week since I've been using FreeBSD now and I can say that in many aspects it feels a better OS than Linux, particularly the base system tools, the devfs system, the /etc/rc.conf interface to system initialization, the kernel module loading through /boot/loader.conf etc. are very convenient and easy to use.

Having said that I strongly suspect that Linux users will find a few gotchas in FreeBSD. Here I will document some of the problems that a "power" desktop user will face in FreeBSD as compared to Linux.

Gnome and KDE issues

Though the common desktop environments, Gnome and KDE work well, it is to be realized that they require some integration with the base hardware for some functionality. 90% of this will work on FreeBSD through HAL and DBus, but there will be quirks. Some Gnome tools do not work as expected or work with reduced functionality: in particular third-party Gnome components which assume a Linux installation.

Without getting too much into detail, if all you want is a desktop with the basic productivity tools, things will work reasonably as expected. However some system configuration GUI tools will not work properly or at all.

Bluetooth support might also be tricky in FreeBSD; at least it will not work through the Gnome bluetooth interface.

3D acceleration for display drivers

FreeBSD does have 3D drivers from NVIDIA (not sure about AMD) but until recently there was no support for x86-64 (commonly known as amd64). But in any case this is not so big an issue if all you play is low-intensive SDL games and don't rely on OpenGL applications.

The sound system - this is my biggest gotcha

Most likely your sound card will work and be supported by FreeBSD, but where the problem lies is in using some common sound and multimedia applications which absolutely rely on ALSA. Now it is well known that FreeBSD and other BSDs continue to use the Open Sound System, while modern Linux kernels prefer ALSA. This means that if you are used to certain multimedia applications that rely on ALSA you're on your own.

90% of sound-related apps work on both OSS and ALSA, but MIDI and music composition tools like Rosegarden and NoteEdit aren't available on FreeBSD as they use ALSA MIDI interface, not OSS. Having said that JACK is available in FreeBSD and applications that use JACK audio toolkit will work nicely.

Hardware and peripherals

This article, which seems to appear on google search results for "FreeBSD for Linux users" is a bit outdated and does not take into account the increasing number and variety of hardware and peripheral devices especially for mobile computing.

He says "most common hardware that is supported in Linux should be supported in FreeBSD" and you will be affected only if you *own* that piece of hardware which is not supported. Now for desktop systems this might hold true, but as many of us use laptops, I can confidently say that Linux support for laptop hardware would definitely be on a higher level because of the sheer number of people who use a variety of hardware on Linux and the fact that some of them have the technical capability to write device drivers. The FreeBSD community is simply not large enough to care about certain uncommonly used peripheral devices while Linux has a much better and wider support for uncommon peripherals like webcams and certain USB input devices like WizardPen-based pen tablets.

While input devices like pen tablets require an Xorg driver which might be available on Linux, not all of them are easily portable to FreeBSD as some of them rely on Linux kernel calls. Webcams are a different issue and you won't be able to use most internal or external webcams which Linux supports using the uvc (USB video class) drivers.

Again, some wireless cards might not be supported, but this is becoming less and less of an issue these days.

Conclusion

On the whole this is not a discussion on pros and cons of FreeBSD but merely issues which Linux desktop users have to be aware of before they think of using FreeBSD full time.