I ranted about the new Unity interface some weeks ago. On several occasions thereafter, I had to help people solve problems they had using some sort of graphical user interface.
Example I: I was debugging a broken VPN connection. The connection
settings were managed by the KDE network manager, which is rather easy
to use. Internally, of course, the network manager just writes out
some temporary configuration files and starts the PPP daemon with a lot of
custom flags. That's all fine if it works – but in this case it
didn't work. It just said: "connection failed", no diagnostics given.
(The solution was to enable
MPPE,
which itself was trivial: ticking the corresponding box. How did I
find this out? Tailing /var/log/dmesg while connecting. It said
right there: MPPE not enabled, but server side requires it.)
Example II: The gnome network manager somehow fucked up. Even now I don't know why. It says "connecting", and then nothing happens. No diagnostics.
UNIX is simple. It really is. There is a reasonable and easy-to-follow philosophy behind it. But UNIX requires the user to know what he wants to do, and read error messages. UNIX simplicity is not the same as iPhone simplicity.
Eric S. Raymond wrote this set of rules that should guide UNIX program design. In this context, two important rules stick out (emphasis mine):
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Although this is of course mostly aimed at text user interface programs, you can get an important point here. Most GUIs adhere to the Rule of Silence quite well – in fact so well that they seldom say anything at all!
Since many UNIX GUIs invoke text-interface programs under the hood, it should be a necessity to be able to view how those program failed. Luckily, most TUI programs provide descriptive error messages. If they are hidden in the GUI there are two effects:
I don't use GUI programs at all, except for a Browser (Vimperator/Firefox), a PDF viewer (Zathura) and The GIMP. Mostly, this is because of usability considerations. But also, I'm afraid to use a computer where I cannot see what is happening. And that's exactly the case with GUIs that do stuff that can fail: I don't know what they are doing and why they are failing!
I the end I always go the extra mile and read up on the PPP daemon, for example. This wouldn't be necessary if GUIs had a switch to do some really verbose logging. That would help tremendously. Plus a button to display that log. Should be easy, shouldn't it?
Often, if you need to know which files are accessed during the startup of an application, you are stuck searching for them in the manpage. Also, probably not all of them are documented there.
I use strace to find these files:
strace -efile /usr/bin/program 2>&1 1>/dev/null | grep ^open | cut -d\" -f2
Note that unless you place the grep expression in between this will
give you all syscalls that involve files, i.e. also simple checks
whether a file exists or has a certain permission set.