Re:Text import in 1.0.x was slow
on
Gnumeric Turns 5
·
· Score: 1
1) depends what you mean by 'change' (I'm feeling clintonian:-). 1.1.x has hooks to support real time data feeds, and a sample implementation. That would allow some cells in a worksheet to depend on external content that updates. There is also a CORBA interface with a fair amount of bit rot.
2) We suppot MS Excel style format specifications so you can format a cell as mm:ss.000. Is that what you're looking for ?
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.
Re:Gnumeric doesn't do Pivot Table
on
Gnumeric Turns 5
·
· Score: 3, Informative
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.
Re:I use Gnumeric, but...
on
Gnumeric Turns 5
·
· Score: 3, Informative
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.
Re:But can it do this?
on
Gnumeric Turns 5
·
· Score: 2, Informative
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'
Re:Gnumeric is great
on
Gnumeric Turns 5
·
· Score: 4, Informative
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
Re:"Native" OS X port?
on
Gnumeric Turns 5
·
· Score: 2, Informative
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 ?
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.
Re:Still looking for decent charting app
on
Gnumeric Turns 5
·
· Score: 4, Interesting
Please contact me (jody@gnome.org)
We've got a new charting engine in gnumeric now that will be released as a standalone library after gnumeric-1.2.x. Its goals are similar to gnumeric but on the charting side. Which means that it aims to have a superset of MS Excel's functionality. Thankfully that is alot easier for charts. The framework still needs a few extensions before I'm ready to split it out, but its already pretty capable. Adding a png or svg exporter would be fairly simple.
Text import in 1.0.x was slow
on
Gnumeric Turns 5
·
· Score: 5, Informative
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.
Re:Gnumeric _does_ support Open/StarOffice format
on
Gnumeric Turns 5
·
· Score: 4, Informative
1.1.x has an importer for sxc documents. 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.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.
Re:5 years and autofill still doesn't work right
on
Gnumeric Turns 5
·
· Score: 1
File a few bugs with details of what you'd like to see added. Autofill in general is a vast swath of heuristics. Give us some clear specs and your pet peeves will be added.
I wouldn't turn down a patch either (hint hint).
Re:Looks great, why not for Windows too?
on
Gnumeric Turns 5
·
· Score: 4, Informative
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.
- I'd love to see someone do a text interface to gnumeric. We have a full model-view-controller split, so its feasible to do it./me lays down the gauntlet. Is anyone up to the challenge ?
Re:Gnumeric is ok, but not THAT hot
on
Gnumeric Turns 5
·
· Score: 3, Informative
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.
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
Re:Most annoying 'feature' of MS Excel
on
Gnumeric Turns 5
·
· Score: 2, Informative
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.
I don't really know. Up until last year my desktop was a Pentium 100 with 48Meg and things ran smoothly . I wouldn't want to build on that box, but as long as things don't get too big it should perform reasonably.
Text import limitations in 1.0.x
on
Gnumeric Turns 5
·
· Score: 1
We know. Things are much nicer in 1.1.x
1) Better performance 2) A decent format selector 3) Configurable encoding and locale
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.
Compatibility with existing products is required for people to be able to transition. We already have significantly better analytics than MS Excel. Over time we hope to become a superset of it in other areas too.
Re:Most annoying 'feature' of MS Excel
on
Gnumeric Turns 5
·
· Score: 5, Informative
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.
Slashdot Mirror
1) depends what you mean by 'change' (I'm feeling clintonian :-). 1.1.x has hooks to support real time data feeds, and a sample implementation. That would allow some cells in a worksheet to depend on external content that updates. There is also a CORBA interface with a fair amount of bit rot.
2) We suppot MS Excel style format specifications so you can format a cell as mm:ss.000. Is that what you're looking for ?
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.
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.
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.
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'
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
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 ?
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.
Please contact me (jody@gnome.org)
We've got a new charting engine in gnumeric now that will be released as a standalone library after gnumeric-1.2.x. Its goals are similar to gnumeric but on the charting side. Which means that it aims to have a superset of MS Excel's functionality. Thankfully that is alot easier for charts. The framework still needs a few extensions before I'm ready to split it out, but its already pretty capable. Adding a png or svg exporter would be fairly simple.
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.
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
File a few bugs with details of what you'd like to see added. Autofill in general is a vast swath of heuristics. Give us some clear specs and your pet peeves will be added.
I wouldn't turn down a patch either (hint hint).
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.
- We have a cheesy oleo importer
/me lays down the gauntlet. Is anyone up to the challenge ?
- I'd love to see someone do a text interface to gnumeric. We have a full model-view-controller split, so its feasible to do it.
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.
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
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.
Nice test case. That think took way too long to load. I'll have a look at why.
1) It makes heavy use of VBA macros. Supporting those is still a research project.
2) The button object importer is missing a few attributes. So the buttons are improperly coloured and labeled in gnumeric.
3) It uses EMF images. We don't have a display engine for those under linux.
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 ?
I don't really know. Up until last year my desktop was a Pentium 100 with 48Meg and things ran smoothly . I wouldn't want to build on that box, but as long as things don't get too big it should perform reasonably.
We know.
Things are much nicer in 1.1.x
1) Better performance
2) A decent format selector
3) Configurable encoding and locale
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.
Our goal is to produce a great spreadsheet.
Compatibility with existing products is required for people to be able to transition. We already have significantly better analytics than MS Excel. Over time we hope to become a superset of it in other areas too.
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.
That would be me.
jody@gnome.org