Five years ago I strongly criticized the OpenDocument standard for being critically incomplete for spreadsheets since it left out the syntax and semantics of formulas. As a consequence it was unusable as a basis for creating interoperable spreadsheets.
Off the record several ODF participants agreed. The explanation for the sorry state of the matter was that there was a heavy pressure for getting the ODF standard out of the door early. The people working on the text document part of the standard were not willing to wait for the spreadsheet part to be completed.
That was then and this is now. Five years have passed and there has been no relevant updates to the standard. However, one thing that has happened is that is that Microsoft started exporting ODF documents that highlight the problems I pointed out. ODF supporters cried foul when it turned out that those spreadsheets did not work with OpenOffice. In my humble opinion, those same loud ODF supporters should look for the primary culprit at the nearest mirror. You were warned; the problem was obvious for anyone dealing with programming language semantics; you did nothing.
So given the state of the standard, where does that leave ODF support in spreadsheets? Microsoft took the least-work approach and just exported formulas with their own (existing) syntax and semantics. Of course they knew that it would not play well with anyone else, but that was clearly not a priority in Redmond. Anyone else at this point realizes that ODF for spreadsheets is not defined by the standard, but by what part OpenOffice happens to implement. Just like XLS is whatever Excel says it is.
One implications is that ODF changes whenever OpenOffice does. For example, OpenOffice has changed formula syntax at least once — a change that broke Gnumeric’s import. If you follow that link, you can see that OpenOffice did precisely the same thing that Microsoft did: introduce a new formula namespace. Compare the reactions. For the record, in Gnumeric the work involved in supporting those two new namespaces were about the same.
For Gnumeric the situation remains that we will support ODF as any other spreadsheet file format. Until and unless the deficiencies are fixed, ODF is not suitable as the native format for Gnumeric or any other spreadsheet. (There are other known problems with ODF, but those are somewhat technical and not appropriate here.)
Note: I want to make clear that the above relates to spreadsheets only. I know of no serious problems with ODF and text documents, nor do I have reason to believe that are any.
I decided to give a new OpenSUSE 11.2 a spin. In hindsight, that was probably a mistake.
The new version installs a desktop-optimized kernel. The idea sounds good, but for me it does not work: named consistently causes an Oops or a kernel panic. (I haven’t otherwise had a kernel panic for many, many years!) I reverted to the so-called “default” kernel and the system seems to suffer only a loss of my confidence.
Somewhat more worrisome is that the system seems to have no bladder^Wfan control. The fan remains off until the temperature reaches crazy levels. Then the fan turns on full-blast and remains on until shutdown. In the same department, the backlight controls do not work. The tricks that worked in 11.1 no longer do. I am going to try a bios upgrade and see if things improve.
Ideas, anyone? This is a Toshiba Satellite L305-S5944. Drop me a line at mwelinder at gmail.
Update: I really don’t think 11.2 likes me:
Emacs’ menus are partially broken. For example, in Dired the menus for Mark/Regexp/Immediate/Subdir are all empty.
Valgrind is broken. I get incomplete stack traces for places with full debug info. I get complaints about unrecognized syscalls.
The source repository doesn’t seem to be set up right.
But, hey!, it comes with wobbly windows. What more can anyone want?
It was a really promising application, but it has never been able follow up on that great start. The worst thing is that it is sluggish. Operations that should be instant — like displaying the next image — are not, but take half a second. (Getting a new camera did not help there!) I used to think it was just my old laptop, but with a new laptop that excuse does not fly anymore.
I have now tried Picasa. It is crazy-fast! For now, I am going to use that. The biggest problem was migrating the F-Spot tags. That problem was solved with the help from a Robert Brown on Google’s help forums.
Basically, you need this script to create album files and then blow away Picasa’s database to force a regeneration.
OpenSuSE 11.1 updated the Gnome File Chooser and it now looks like this:
Recall that my premise is that the file chooser’s function is to help the user choose files. By my count, the area used for files is 29% in the above dialog, including header and scroll bar. That simply is not right! Why does the “Places” section (which I rarely use) and its buttons take up that much space? Further, what does the path bar give me that adding the path into the location entry and putting “..” into the file list does not give me?
Things get a lot worse if a file preview is added. Here’s how uploading the above image looked in Mozilla:
There is room for an incredible 2-4 letters of the file names! And the full “Places” and path bar sections, of course.
Could someone please defend the Gnome File Chooser so I do not have to suggest taking it out back and having it shot!
(I do not take comments at my blog, but you can probably find an email address somewhere.)
Thomas, that is a fine rant, but I look in vain for the answer to the question of whether you could get work done after spending 15 minutes learning git instead of cursing it for not having the same command line arguments as cvs. I am sure that with counseling you could get over typing “–help” instead of “-h”.
One of my favourite error messages in from TeX. Stuff this into TeX and look in the log:
It will tell you that “Interwoven alignment preambles are not allowed”. A bit cryptic, you might say, but TeX comes with a manual, i.e., The TeXbook which helpfully explains
If you have been so devious as to get this message, you will understand it, and you deserve no sympathy.
I am not perfect. Therefore the code I write is not perfect. Every once in a (rare!) while I have been known to write code that people of evil mind could use. I deserve blame for that. I do not deserve thiskindofblame.
What we have here is a Python bug: when embedding Python, we (and half a dozen other applications) use PySys_SetArgv according to spec. Python, in its wisdom, uses that as a clue to start loading python files in unexpected places. The right thing to do would be to fix Python as well as any code that might depend on the bug. That was not done.
Somehow it was chosen instead to file this against Gnumeric and half a dozen other applications. As a design error no less. That is simply offensive! Let us hope no problem is found in libc’s malloc, because dealing with bug reports for all users of that would take some effort.
Why does Python get this kind of reputation protection? They screwed up, so let them take the blame and have them fix the bug. If that breaks other applications, well so be it – the Python people will eloquently explain that to their community.
Whenever I update my OpenSuSE installation, the Gtk+ File Chooser Dialog get worse. This is how it looks for me on OpenSuSE 11.1 when used from Gnumeric. It looks more or less the same from Gedit and Mozilla.
I hope I am not breaking new ground when I claim that the purpose of the file chooser is to help the user choose a file. How is that going to happen when the area used for files is less than the size of one button?
I really hope other people are seeing something sane, but this is with a vanilla install, I think. (Note: I mention OpenSuSE 11.1 for reference, not as an assignment of blame.)
I have been running OpenSuSE 11.1 for about a week now. My first impression is that it feels nicer, but that there are severe setbacks that slipped through QA.
It seems to boot faster than 11.0. I was never really bothered by the boot time, so I do not have concrete measurements.
The 30000-wakeups-per-second bug is gone! Yeah!
It’s still Beagle-infested, so everything is dog slow out of the box. I am having a hard time thinking anyone with a laptop really likes to have Beagle on it. Oh well, I simply use rpm to erase anything related to beagle and install Gnu’s locate.
Printing on my hplj-3330 works, but I had to force it to use a non-default driver. That’s not a big deal for me, but it fails the Grandma-test.
I plug in my camera. I am asked if I want to import photos to f-spot. I do. f-spot then starts but tells me “Could not lock device”. A bit of poking around reveals that gvfsd-gphoto2 needs to be killed for f-spot to work.
The Cairo shipped, 1.8.0, is old and has a badly-broken pdf backend. This evidently is known in Cairo land. I wouldn’t expect anything that prints using gtk+ to work right. Also, since Gnumeric’s tests fail, I need to work around that before I can do releases again.