In the grand tradition of nntp-over-rss, let me kick in a word or two
about file choosers. Start by reading what Federico — wrote on the topic.
Regarding Emacs, Federico missed a few important things. (Any description of Emacs that is smaller than the tar ball is incomplete, naturally.)
- Case: Completion in Emacs is (optionally, this being Emacs) case insensitive. This is very useful if you are lazy
with the shift key or just happens to get a lot of filenames via a
- The Tab key will, after completions have been listed, scroll the completion window when you press it again. (I actually wrote that a decade or so ago.) This makes it possible to
navigate large directories fairly easily. A drop-down like the one
the GTK+ file chooser provides is not useful for this. Note, btw.,
that this feature also makes completion useful in keyboard-only mode.
- A completing Tab that ends up with multiple choices left does not also list the choices
for two reasons: (a) it is slow on a 9600 baud terminal and (b) if you are just using the Tab key to speed up entry you generally do not
want the list of possible matches until you are not making progress. The latter is still valid and
prevents the UI from getting in your way. The FileChooser’s
completion is very much getting in the way: it steals focus and
obscures parts of the dialog you want to see.
In my experience this means that the Emacs completion is useful while
the FileChooser’s is not. That is especially true in directories with hundreds of files. (And that is before we discuss bugs that cause people to overwrite files they did not intend. The current state of save-as is somewhere between “barely usable” and “dangerous to your files”.)
On opening files: suppose I want to add a “gtk-button-images = 0” setting in ~/.gtkrc-2.0. Why do I have to use two different UIs depending on whether that file already exists? The logical extension of that would be to have two entirely
different UIs for save-to-new-file and overwrite-existing-file; we
are lucky no-one in Redmond thought of that, I guess,
This should not be too hard to fix — I will have a go at it in a
On screen real estate: The GTK+ file chooser gives
me a vew of 7-8 files (typically directories, actually) when it comes
up. To locate a file I have got to scroll which is a bit hard with
such a small viewport. Emacs, on the other hand lists files in
batches of 36 files. Guess which one I find more useful. (This
is actually for a large part a treeview issue.)
All the above comes through a little more negative than I really
wanted it to. I do appreciate all the work that Federico has put
into the FileChooser. My goal is not to assign blame for where we
are — that would be pointless or worse — but to get us to a better state.
I must be doing something wrong. Getting kids to eat right is supposed
to be a major fight.
Yet _L_ drinks his milk, eats his carrots, cannot get enough broccoli, loves porridge,
and if we are getting pizza then he wants it with spinach.
_A_ is not much worse. While she does complain, that generally stops
after we tell her “you get what you get and you don’t get upset”.
(That is a nice trick from the daycare.)
If I told you that I ate like that myself, my nose would grow faster
than a speeding bullet.
Applications that support multiple windows should support multihead
displaying, i.e., it should be possible to put some of the windows
on a separate screen. If you are blessed with two screens it is
a very nice productivity improvement to use that extra screen for
reference materials relating to what you work on. Applications
that support this are cool.
Gnumeric is cool, of course. Emacs is cool. Mozilla is not cool.
Unfortunately multihead support is a bit of a late add-on for GTK+.
The duct tape is visible here and there. For example, every time you
create a widget for the non-default screen, you in effect build it
for the default screen with all the setting that relate to that,
then warp it over to the other screen and redo all the settings.
Anything that relies on settings — icon sizes, fonts, etc. — needs
to be done or redone when the widget is realized.
But GTK+ is better than the rest of the Gnome stack. There are
still places that build X cursors for the wrong display, fail to
catch screen-changed signals, or grab the cursor on the wrong
display. The results range from the cute (popups and menus show on
the wrong screen) over the irritating (application crash) to the
worse (grabbed X cursor).
It does not look like I can push the dependency life cycle as far as
I had hoped. Specifically I do not think it can remain alive for a
sheet that has been deleted but still lives on in the undo queue.
Bummer. I will probably have to recreate it on undo.
On the bright side, I managed to clean up the dependency shutdown process a bit and speed up exit for large sheets.
Rotation went well, except that Excel’s semantics is even worse than I described. It turns out that the placement of text in a cell depends on whether a border — even a top or bottom border — is present.
I think we do everything right for the text except for the fact that rotated text
in Excel is not clipped, but extends into neighboring cells even if
those cells have contents by themselves. I fake it by just not
clipping, but we need a new span type to get it right. (We also need to shear borders and background; given that we can point at OO-calc
and say “only partially supports rotated text”,
One of the most advanced and delicate piece of Gnumeric is the system
that tracks dependencies, i.e., keeps track of what cells depend on
what other cells. The data structure has to be able to quickly answer
questions like “what cells depend directly and indirectly on
cell A1?”. Building the structure also needs to be fast so large sheets load reasonably fast.
The most obvious choice — a simple per-cell list of
direct dependents — simply does not work well, for example when
a formula like =MAX(A1:T50000); you probably do not want to create a
million little lists for that.
Add in dynamic dependencies — A1=”B42″ and A2=INDIRECT(A1) — and
already complicated code gets worse. (Lots of people like to
use INDIRECT even though in my experience it is always the wrong
function to use. Some of the table lookup functions are generally
conceptionally much better suited and avoid that computed-goto
A tiny mistake and while
our test sheets may work perfectly fine, someone else’s do not.
Oh, yeah, I have been mucking with that code this weekend.
Bruce Byfield posted a comparison of three spreadsheets, namely OO-calc, Gnumeric, and KSpread.
Unfortunately he does not seem to be a spreadsheet user and the tests
he puts the programs through — while all relevant — are very basic.
It is a bit like comparing word processors only on how well they write
one-page letters. Here are some things that an in-depth review really ought to have included:
- Excel compatibility. He wants to compare spreadsheets for office use and he says nothing about Excel compatibility? That’s a gaping hole, in my humble opinion. In the office world you just have to be able to take an Excel file and import it and have it work by and large the same. I think Gnumeric does quite well here, particularly in the function and evaluation semantics department.
- Big spreadsheets. What would he have seen if he had taken one of the corporate or scientific monster spreadsheets and used them for a test? Generally, OO-calc would load the sheets albeit slowly; Gnumeric would load them faster, but not as fast as Excel; KSpread would roll over and die. The speed tests he performs is
like testing C compilers on “Hello World”.
- Accuracy. If he had looked at other comparisons
on spreadsheets he might have noticed that conventional wisdom is that Gnumeric’s functions compute things accurately while Excel does not. OO-calc and KSpread are still at the Excel level. And for the record, Gnumeric computes accurately not simply because we took R’s functions, but because we also heavily improved them and actively seek to return those improvements.
- Cross platform. OO-calc would win here because its Win32 support is still better than Gnumeric’s. But Gnumeric is getting there and unlike OO-calc (as I understand it) runs fine on 64-bit machines.
- Scripting. Gnumeric is lacking here. One can write new functins in Python and Perl, but that is about it. We haven’t gotten to programmatic control of the sheets yet.
Everybody and their brother have their own model for dealing with
Postscript (as I understand it) simply rotates the coordinate
Pango rotates the image and then translates the origin to be
the upper-left of the rotated image’s bounding box. (It used to be at the top-left of the first letter.)
Excel (for a positive angle) rotates the individual lines of
the image and positions them side-by-side (so the lower corners are all on a horizontal line)
in such a way that the first line is translated just enough to the
right to make the text be below a hypothetical line starting at the
origin and having the desired angle from the X-axis.
Pango’s is weird, but the pixel image is at least continuous as a
function of angle. (Well, actually not, but that is because of a different
issue: hinting is turned off for non-zero angles.) But Excel’s?
As the angle goes towards zero, the image translates continously
to the right. If the angles were real numbers, the image would
translate all the way to infinity. Then, suddenly, at angle zero
everything snaps back to the origin.
The job then is to implement the latter in the world of the two
You saw it here first. Gnumeric 1.5.1 is making
its way to the mirrors as these bits fly. It feels stable, but
there has been a lot of recent shuffling in core parts.
Think of Gnumeric (in general, not just the new version) as the Gnome guinea pig:
- We do multihead display
and had to clean up the library stack not to crash with it.
- Multiline, right-justified and rotated Pango layouts that make Owen bite his lip? That’s us.
- 100k-lines treeviews? Every day.
- Planet-sized canvas? You bet.
- Online documentation the size of “War and Peace”? Certainly.