Tag Archives: Gnome

GNOME’s disk usage analyzer Baobab in Debian

In case you’re looking for GNOME’s graphical equivalent of “du” command which provides a tree overview of disk usage of each directory, and you are a Debian user, know that program Baobab is located in package gnome-utils.

Response to: Why does the “Open File” dialog exist?

This is posted in response to Dan’s original post, but since it turned in such a long rant (longer than 4096 chars), I had to post it on my blog only.

Hi Dan, here’s a few more programmer’s thoughts as a follow up to your reply-comment.

First, I am currently an ITC student, but I’m also programming for living :-)

Second, I’m also not a GTK programmer, and it’s been a while since I worked on a GUI app (I’m mostly into games now). Last time I had dealings with dialogues of any kind was university assignment with .Net … and I loathe .Net so …

Anyways, I’m digressing too much. Still, I have no idea how much you’re programming, so I’m really sorry if I’m digging too much to the basics, but better to say too much than too little, eh?

You said “An Open File Dialog returns a value – the URI of the file selected – and blocks input to the program creating it until the user clicks OK.”
I don’t think that either of these are more than customary. Why can’t “Open” leave the main window unblocked?

Quite simple. We programmers are lazy and sequential beasts. We prefer doing stuff this way:

void mnuFileOpen_Click()
// first arg: vb6-style spec of filetypes
// second arg: default filename, or default path
std::string filename = GUI_OpenFileDialog(“*.cpp|C++ files;*.h|Header files;*.txt|Text files”, “/home/user/”);

if (filename == “”)
return; // cancel was pressed

// otherwise, parse stuff

See, we prefer to transfer full control to the dialog. This means, at the same time we’re not doing the so called main-loop:

while(1) // repeat forever
GUI_Event event = GUI_GrabEvent();


This handles all GUI responsiveness. So, if GUI of the app would not be responsive, then should we really allow the user to try clicking on the app (which would not respond anyway)? No, that’s where modal dialogs come into play.

Overall, we depend on operations being sequential, and we like when operations are synchronous.

But sometimes, we simply can’t depend on ops being synchronous – user might just have to do something in the GUI. We can do asynchronous calls… but really, most of the time apps are so simple user doesn’t have much to do in the main window. And also, today most apps do have the option to give users non-modal open file dialogs. So why don’t they do it? First app that comes to mind that should do it is Firefox/Iceweasel.

Programmers are lazy, and if they ever want to finish the project they started, they must never try being perfectionists and over-complicate the project!

Why can’t “Open” leave the main window unblocked? Why must the open dialog return anything to the application (it could just open a file with the corresponding application)

The point of the whole “Open File” dialog is: “Hey there, operating system/GUI library, please present the user with a nice dialog so that he doesn’t have to enter the full path!”

That is, “Hey there, OS/GUI, give me the filename so that I don’t have to ask the user directly”!

In other words, the OS/GUI is the one that actually decides to show the user the nice “open file” dialog.

[original post]

Now let’s go back to your original post. Why is calling nautilus probably a bad idea?

Nautilus is big. Nautilus is not XFCE’s primary file manager. Linux users love choice, that’s why most of us use Linux. I don’t want too much stuff integrated or interdependent. I want to be able to use KDE apps on XFCE without KDE libraries loading too much of their bloat.

But, you’re also approaching it from completely wrong direction. It isn’t the file open dialog that should be using Nautilus; it’s Nautilus that should be using the File Open dialog! That is, let’s use in Nautilus the same drawing library that generates the File Open dialog.

Now, final reason is … you actually can already use Nautilus as your File Open dialog. Just doubleclick on your desired file and that’s it. Not only that, apps can create custom actions. Additionally, when you doubleclick on the associated file, the best apps also detect they’re already running, dispatch a message to their main instance and shut down immediately (which seems to you as “Look, GIMP saw I clicked on the file and opened it instead of opening new instance — cool”, but actually a new instance did open and dispatched a message).

So what you’re proposing is already integrated. The only thing you’re asking is that Nautilus and its file-managing brethren can filter according to extension, and that apps actually call Nautilus and its file-managing brethren with the filter argument.

That’s simply not going to happen any time soon, because programmers don’t want to depend on your behavior with the file open dialog – I mean, Nautilus. They want a simple and clean behavior of the file-open function: it either returns the value “” (empty) meaning “cancel”, or the value “” meaning “ok”. User also doesn’t want the confusion: “Look, I’m in the Nautilus window, and when I double click on file, the dialog closes.” It’d also be hard for user to distinguish if it’s an actual file-open dialog or Nautilus.

Again, if you turned it the other way around (widget used to render icons and handle clicks for File Open dialog also being used for rendering icons and handling clicks in Nautilus — this is what Windows is doing) that’s a good thing. Because for Windows t works great: I can get “File Open” when sending file through Skype, notice “Ah, frakk, I didn’t update to latest SVN revision”, right click on empty space, choose TortoiseSVN’s “SVN Update”, and get the latest version straight from there.

But I’m still not seeing Windows Explorer as the file open dialog. Instead, Windows Explorer is using shell functions to display the same things in same way as the File Open dialog.

I hope this rant clears things up.

Debian/Ubuntu Gnome: Restoring Nautilus as default folder viewer opener

So, you installed Thunar, PCManFM, Dolphin or Konqueror and now when you doubleclick on a folder on your Gnome desktop (techically, nautilus desktop) or choose a folder in your Gnome panel, you don’t get Nautilus? For all files you can choose the default program to open with, but not so with folder?

Honestly, I don’t know what smartass from Gnome team thought it’s a good idea to honor, occasionally, setting set through external file that specifies which program to use for opening folders … yet to provide no way to change this through GUI. Especially when you already support same thing for all other files!

So let’s change the default folder handler manually!

This problem occured to me a lot of times by now. Solution is quite simple and completely nonintuitive.

Key file is


This file is one source of information for which program to use to open a specific file type. File types are designated by their mime type. Folders are internally listed as “x-directory/normal” and “inode/directory“. From my experience the latter one is actually being used.

So let’s edit this file. Edit /usr/share/applications/mimeinfo.cache as root. Now, find the line which starts with “inode/directory“. In that line you’ll find “nautilus-folder-handler.desktop;“. Together with the semicolon, move it to be the LAST entry in the line.


Original line:


Edited line:


I’d now recommend that you restart nautilus. Easiest way is logging out and logging back in.Or run “killall nautilus” from shell; this should shut down nautilus, but the session manager should restart it immediately.

Hope this helps. Questions and comments welcome.