Tue, 31 Mar 2009
Is Ekiga Doomed?
I am more-or-less happy user of ekiga. However, with the latest GNOME release (or two), I am not sure about its future. The new GNOME contains a new instant messaging and voice-over-IP application, Empathy.
I have not tested Empathy yet, but the list of supported protocols look impressive. I wonder how complete this support is, however (like GPG in Jabber/XMPP, SIP call redirection, SIP from behind of NAT using STUN or proxy, etc). I am trying hard not to be a skeptic, but maybe ekiga will join the following list of doomed applications:
- GDM 2.1x
- The rewrite of GDM in Fedora 8 (not sure about version numbers now) took away most of the options (such as the X server command line, automatic login for single-user systems, XDMCP(!)), most of the features are not restored even now, year and half later.
- Sawmill/Sawfish
- It has been deprecated in favor of Metacity, which still cannot do such a simple thing like sending a window to the different workspace using
Ctrl+Alt+Rightand return back by releasing bothAltandRight, and pressing theLeftkey while still holding theCtrlkey. Metacity still requires theCtrlkey to be released first. - Galeon
- Has been deprecated in favor of Epiphany, which still plays catch up
with Galeon feature set (even with its
epiphany-extensionspackage, and despite of the fact the development of Galeon has been dormant for several years now).
I could probably name several other projects. May be this is a trend in GNOME: replace the existing full-featured apps with half-retarded new ones, just because you do not agree with architectural decisions of previous developers, or because (in the GDM case) you need one more feature (fast user switching) which is hard to do in the present code base. And then promise to implement all other features users are used to, and fail to fulfill the promise in several years. In the meantime, get your code merged to the GNOME code base, kicking the previous full-featured application out of it, making the life of its developers harder, and thus cause the development of it to slowly die off.
Mon, 30 Mar 2009
Firefox File Input
The daily user-interface annoyance award herby goes to the Firefox (or rather XULRunner,
which means this is present also in Galeon). The problem is in forms
in the <input type="file"> fields. It looks like this:
In Firefox and Galeon, it is impossible to write directly to this field. Which means that even if I already know the file name and can type it really fast, I have to click to the input field, wait for the file input dialog to pop up and get focus, and only then I can type the text in.
Is it possible to disable the pop-up (or make it appear only after clicking
on the Browse button)?
Sun, 29 Mar 2009
The Oldest Real Bug
I occasionally complain about bugs remaining unfixed for a long time in the Open Source Software, and it really hurts when I spend several hours trying to solve a problem, which turns out to be a known problem reported many years ago, still unfixed.
In our archive of graduate theses, we had a problem that some PDF file could not been displayed when being accessed through the
public part of theses.cz. Displaying it from the authenticated
part of this site or downloading it from either part and then displaying
it locally was OK. Later we have found that even displaying the file from
the public part was OK, provided that the HTTPS instead of HTTP has been used.
The problem is caused by caching: Mozilla thinks it cannot cache the
files downloaded over HTTPS, while it can cache the files downloaded
over HTTP. Mozplugger then does a shortcut of running the PDF viewer
with the file name from the Mozilla cache for the HTTP case, but
downloading the file separately into /tmp directory for
the HTTPS case. Now when the PDF file is bigger than the cache size
limit, Mozilla deletes it from the cache just before Mozplugger starts
the PDF viewer.
This has been reported to the Mozilla Bugzilla in March 2003, six years ago. The latest comment was from May 2004, and the bug is still there. The bug has a "QA Contact" field pointing to a non-existent address, so there is even nobody to complain to. We have worked around the bug by adding an HTTP header which causes Mozilla to avoid caching of the PDF file altogether. I have also reported it downstream, to the Fedora bugzilla, hoping they would know better than me how to push it upstream.
Sat, 28 Mar 2009
Git Snapshots
In his excellent article Git from the bottom up (PDF warning)
John Wiegley writes on page 26 about using
git-stash(1)
as a way of snapshotting the work in proggress, e.g. from cron(8).
He suggest to do git-stash && git-stash apply every hour or so.
It is a nice idea, but it has a problem:
It changes the data under your hands, and there is even a short
window of time (between the stash and apply),
when the local changes temporarily disappear from the working tree.
So during this window it is not possible to e.g. open the file with the
text editor and expect it to have the contents which has been written to it
just several seconds ago.
Can snapshotting be done in Git correctly? Something like "save a current working tree as a new unreferenced commit"? How do you make the snapshots of your work, my dear lazyweb?
Fri, 27 Mar 2009
Status Update
I am still alive, but busy doing a real-life work rather than writing about it :-) In the meantime, I have received my results from the JLPT 3 exam: I have passed, but with lower points than I had from JLPT 4 last year. So the next step would be JLPT 2, requiring about 1000 more words and 600 more Kanji, definitely not a task for the next year only.