Slashdot Mirror
Gnumeric Turns 5
Jody Goldberg writes "Five years ago, Miguel committed the first code for Gnumeric to CVS. In a testament to the quality of the code several lines are still in use. Since that time the project has grown to more than 300,000 lines and now supports all 325 worksheet functions in MS Excel, plus almost 100 more. This seemed like a good time to thank all the people who have contributed to Gnumeric over the years. We're about to start the run up to the the next stable release which will be out in a few
weeks and we look forward to continuing work with GNOME, and the community at large to produce the most powerful spreadsheet in the world."
Gnumeric is an Excel clone, therefore it has the same limit.
The default size is the same as MS Excel (256x64k). That helps ensure that all the funky xls files out there that depend on those limits work out of the box. However, those values are simple #defines. All coordinates are 32 bits internally. A quick edit and a recompile will change the bounds.
see the list archives.
The short answer is yes, but it's an issue that is being looked at.
-- Have you ever imagined a world with no hypothetical situations?
You apparently didn't have Gnome already installed.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
It's not quite ready for prime-time yet, but this is getting closer to being able to code your macros in Perl.
About half true...
4 Its unstable
The kernel is stable, its just KDE and GNOME that crash a lot.
8 It doesn't run Windows programs
There is software available to do this.
9 You cannot buy a computer with Linux
They sell them at Wal-Mart.
14 Un-american
Explain?
17 Anyone and their 14 year old brother can add (buggy) code
All code has to be approved.
Well... do you program? They need those libraries to function, it's a much better thing than writing all the functionality from scratch. Reusable libraries make programming large applicaions, or even small ones, much easier. You don't want to reinvent the wheel everytime you write a program.
It's my understanding (I'm sure lots of people will correct me if I'm wrong) that you can't necessarily just compile->run apps between desktops.
If I recall correctly, it has to do with the gnome desktop using c/GTK bindings, while the KDE desktop uses c++/QT bindings.
Karma: Food Fight (Mostly affected by Date Plate).
also, gnuplot is VERY hard to get it to look good. its the best, but it is really the graphing equivalent of LaTeX. you will never get that quality form a WYSIWYG graph program. havign said that, i so really think grace is a beautiful 2D plotting program (2D has gotta be emphasised, gnuplot beta just kills everything in 3D).
i remember having a discussion on the gnumeic mailing list about this very point, and they said that guppi gives a mass of power to graphing, which they have never even tapped in to. beyond the basics.
thats besides all the technical difficulty of getting 2 COMPLETELY different applications to talk with each other...
.xsession my friend, this is where this kinda stuff is supposed to go...
Cobra::ORBit
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
It's true that Gnome apps use GTK and KDE apps use Qt. However, GTK and KDE interoperate extremely well thanks to the efforts of freedesktop.org.
It may surprise you to hear that you do not even need to run a Gnome or KDE to use their applications. I'm running a blessedly clean IceWM setup and I still get to use Evolution.
If you can infer from this comment from Jody.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Format, I don't know. But VB is not supported as a scripting language, so Gnumeric is imune to macro virus exploits.
aurelien
There are two somewhat related issues to contend with.
1) The file formats are semi documented. We have rough ideas of what OLE2, BIFF[5-8], and escher look like. There are however, lots of abiguities and question marks. As a result we have lots and lots of validation on what get imported. OOo does the same, which is why we can frequently crash MS excel when adding something new to the xls exporter, but still be able to read each others output.
2) The format for VBA is undocumented a far as I know. OOo has a few guesses in place and I've started doing some research on it, but neither of us can even read the vba enough to worry about running macro viri.
3) what scripting capabilities we do have (eg in python, perl, or guile) are strictly sandboxed. We are definitely tending to err on the side of caution rather than functionality.
1) Yes a couple of the routines are still subsets, but they tend to be corner cases (eg CELL). We'll need to finish them off before 2.0.
2) The web pages need work. I need to regenerate the function docs based on current CVS and setup some links from the status page to the docs.
Anyone interested in helping out ?
short answer :
:
I'm lazy
long answer
Ya Ya I know. We'll get to it one day. Its not a terribly interesting problem right now.
Correct versions of several functions that are broken in MS Excel. We need to support their incorrect values and the right answers so that imported workbooks stay the same.
More Statistics
More Random distributions
Lots of financial derivative pricers
1) In early 0.x versions we required you to set an env var before you could _overwrite_ a file in an exporter that was under development. Which seems pretty reasonable for a development release. That requirement was removed for all exporters before the stable series (1.0.x) was release a year and half ago.
2) The lines are
Sheet *
sheet_new (Workbook *wb, char *name)
{
Sheet *sheet = g_new (Sheet, 1);
do stuff
return sheet;
}
Ok they're not exactly high art, but Miguel started this project, and I believe in giving credit where its due.
We're working on it. There is only one remaining technical requirement that is not available under win32, and the new egg menu/toolbar code will fill that slot nicely. Having a win32 build is a high priority. It may not make it in time for 1.2.0 next month but it will go in before the end of the year.
1.1.x has an importer for sxc documents.
.gnumeric exporter for OO one day, but don't see much use in it given that we can read their native format and their xls.
It could be improved, but the heavy lifting is in place and the rest just requires some attention to detail. An exporter will be added eventually.
I'm tempted to write a
Please don't judge all of gnumeric based on the text import in 1.0.x. There have been lots of performance improvements and enhancements there in the development series. The core of gnumeric is easily capable of handling that magnitude of data. Try 1.2.x when it comes out next month (or even 1.1.x if you want to help beta things).
MS Excel is still somewhat faster mainly due to its memory foot print. It was written back in the day and bit bashes things all over the place. Gnumeric pays a penalty for using 32bit addresses rather than bit bashing 18.
If you have something that performs badly please _tell_ us. Our goal is to produce the best damn spreadsheet around. This is still version 1.1, 2.0 (extend) and 3.0 (extinguish) aren't due for a while yet.
We tend to split extension into 2 areas
1) writing functions. Which is supported and documented in python, perl, and guile (and of course compiled languages)
2) scripting. Which is currently unfinished and intentionally mostly undocumented. There are some experimental bindings for python, but we have not had the time to select a solid enough api that we could commit to it. Gnumeric tries to under promise features, and I don't want to whip out some half baked api. The 1.3 development cycle will target scripting and we'll likely wrap the selected api in python, perl and corba initially.
We could use some help on this.
A truely native port is possible, would be alot of work. I'd rather see a native version of gtk+ for OSX. That would help alot more projects.
How far are the various ports from being usable ? I've heard that film-gimp has been working on gtk-1.2, but have not researched it. Are there any gtk2 efforts in the works ?
Gnumeric has significantly better statistical routines than MS Excel. Some are home grown, others are from R.
Our charting utilites still have alot of growing to do. Hopefully with the new framework in place now we can start to accumulate features to target something like grace/xmgr
undo levels are configurable.
You can set the number of levels, and a logical size limit. undoing filling an entire column is more expensive than entering a value.
Most everything else is 'limited by memory'
I found OOo more compatible with recent MS Excel formats. But Gnumeric starts and runs way faster. So, when I don't care about excel files I always run Gnumeric. Functions I need are basically the same.
Less is more !
It's compared to MS Excel simply because it's the best spreadsheat application around. Just as the Gimp is often compared to Adobe Photoshop (originally a mac application) and MS IIS to Apache.
1) If you can crash it please _tell_ us s othat we can fix it. 1.0.x has been very stable.
2) The interface to guppi was weak in 1.0, the new engine in 1.1 is much better integrated.
3) I'm not clear what you mean for the sorting dialog. File a bug.
4) We have started moving past MS Excel in places. Improvements to dialogs, more functions. We first need to have a foundation that can cover the existing fetures before adding wild new ones or no one will be able to leave MS Office. People generally want to bring their data with them to new applications.
There are certainly features of MS Excel that Gnumeric does not support yet. Pivot Tables and Conditional Formats are the main outstanding issues and are targeted along with scripting and accessibility as the top priorities for the 1.3 development cycle in the fall.
The 100% figure refered only to the worksheet function coverage. Sorry if that was not sufficiently clear.
If you've got any workbooks that we don't load properly please send a bug report. There is a confidentiallity protocol available if the data is sensitive.
We now use utf8 internally and pango to display content. I did a fair amount of testing last year importing various asian languages, and have recently started testing hebrew to validate the R to L support. So things should be on pretty solid ground for 1.2.
Our core file format is utf8 encoded xml, so its not really an issue.
Again, you simply fail to understand. _Miguel_ was the sole cause between the Gnome vs. KDE divide. KDE itself was _always_ free and GPL. Simply because it uses a widget toolkit which was less-than-free does _not_ make KDE itself less-than-free. It was entirely possible to recreate a free Qt (which did happen to some extent). Miguel convinced a large population that KDE was close to proprietary, or not free. The whole reason for starting GNOME was because supposidly, KDE was not free (Miguel's thoughts). Now that KDE is completely free (Miguel's "free") why do people continue on working on GNOME? Unified desktop my ass. This is about Miguel and Miguel's ego and business: Ximian. Nothing more.