One suggestion regarding sorting: it would be very useful if you add the following functionality:

------------
When you right-click in a column header, the contextual menu includes the option "sort using this column as key". This save the users lot of clicks for a usual operation: sorting data using only one column.
------------

Further suggestion:

------------
When you CTRL-select columns a,b,c ...n and you right click in any of the selected, the contextual menu includes the option "sort using this columns as key". OO should treat the key as formed by columns a,b,c ... n in the same order as selected.
------------

IMHO, this are the kind of features that can put OO ahead of other not-so-cool office suites... for example Microsoft Office :-)

Posted by orlando_ombzzz on November 17, 2008 at 07:50 PM CET #

Thanks for your suggestions. The first one depends on the sort behavior when a whole column is selected, which is currently in progress (issue 60401). We can consider your suggestion when that issue is finished.

About the second suggestion: We don't currently keep the order in which a multiple selection was made, just the resulting state of which cells are selected and which aren't. So this suggestion would require larger changes to selection handling, and probably won't be implemented in the near future. Maybe later.

Posted by Niklas Nebel on November 18, 2008 at 10:14 AM CET #

"[...] (issue 60401). We can consider your suggestion when that issue is finished."

Thank you for your response.

orlando

Posted by orlando_ombzzz on November 18, 2008 at 12:19 PM CET #

Shit, cool, yeah. But where is OTF support under Linux, where is SVG support, when will the list options dialogue be simplified and when will Openoffice.org start to look like the desktop that's surrounding it? When will Sun actually open up development, when will the people at Sun and Novell get the idea that an office suite is not determined by how many programming languages it is scriptable?
In short: when will bold steps be taken?

Posted by Sé Sehm Troll ess Ohlvehs on November 20, 2008 at 10:44 PM CET #

These features are from outside of Sun.

If you're interested in larger steps, look out for things to come from the ux project, but that's not for 3.1.

Posted by Niklas Nebel on November 21, 2008 at 10:31 AM CET #

give us a link to ux project stuff please?

Posted by sven on November 25, 2008 at 03:30 PM CET #

Right now, only http://marketing.openoffice.org/ooocon2008/programme/thursday_1413.odp , but there's supposed to be an announcement soon.

Posted by Niklas Nebel on November 25, 2008 at 05:08 PM CET #

Sé Sehm Troll, how immature can you get? What you're basically saying is "Wah! Why didn't they do my feature first?" Clearly, OpenOffice.org is making real progress on useful features, and I don't think you have any right to complain.

Posted by Matthew Flaschen on December 01, 2008 at 02:24 PM CET #

Calc still has the worst calendar date entry of any application on the planet. It tries to do "intelligent" reads of fields, but the intelligence is seriously lacking. It assumes that countries, rather than industries, format dates in a preconceived manner, but it's nearly always wrong. The result is that Calc makes serious errors by making unwanted assumptions. Also, there doesn't seem to be any way to force Calc to stay with a default calendar date format; Calc always reverts to whatever it feels like doing. This means that a Calc worksheet can't be handed off to colleagues when dates are involved.

Posted by JJ Joseph on December 01, 2008 at 07:40 PM CET #

R1C1-formulas just implemented in 2.4.1 .. luckily I discovered the movement from menu entry "Format - Tables" to "Options - OOoCalc" .. many thanks 8-)

An urgent wish remaining: "Propagating of template tables".
A common basic task of building Calc projects is to design some template tables and then propagate this templates.
"Edit - Table - Move/Copy Table" is unusable for propagating, because it does not propagate names defined in the template. E.g. a template holding 60 names 20 times copied gives 21 tables with no more than 60 names - in this case I need 21*60=1260 names.
Implementation requires (1) introduction of names with a scope "local" to a particular table, additionally to already implemented names with "global" scope, as a precondition for "reusability" of a particular name in another table, (2) according enhancement of dialog "Define Names" and (3) automatical adaption of formulas on copying of a table.

Additional benefit: a severe shortcoming of xls import could be fixed subsequently.

Posted by RolandE2 on December 02, 2008 at 02:16 AM CET #

Switching to R1C1 isn't finished yet (see http://qa.openoffice.org/issues/show_bug.cgi?id=72191 ). Some distributors include unfinished features in their builds.

Sheet-local named ranges have been requested before (http://qa.openoffice.org/issues/show_bug.cgi?id=60108 ), but that isn't planned for any specific version yet.

Posted by Niklas Nebel on December 02, 2008 at 03:44 PM CET #

Open up a huge new field for Calc by extending date functions backwards as early as possible eg 1/1/1000 with a customise wizard to all local users to enter the dtes when their countries change from Julian to Gregorian calendars. Would provide much needed functionality for historians, genealogists, climate historians and etc and give leading edge over other Office suites.

Posted by Bill Chadkirk on December 03, 2008 at 09:48 AM CET #

A nice idea, but probably targeting too few users to make it into OOo.

If we had support for pluggable number formatters, it could be done as an extension. But currently, that's not possible.

Posted by Niklas Nebel on December 03, 2008 at 06:12 PM CET #

What about the calendar date problem mentioned above? Is there any chance of this being fixed in a reasonable time? As pointed out, there's a whole bunch of date issues that need fixing.

Posted by O'Reilly on December 03, 2008 at 08:07 PM CET #

I don't really understand that description of the date problem above, but if it's about issue 33723 (http://qa.openoffice.org/issues/show_bug.cgi?id=33723 ): Yes, that should be changed, it should be done soon, but it's not currently in progress.

Posted by Niklas Nebel on December 03, 2008 at 08:27 PM CET #

I can see that the techs don't understand the calendar date issues(s), probably because they're not daily spreadsheet users. You can see in the "Issues" page where they routinely close or ignore the issue because they don't understand what it is. Being able to turn OFF the smart date features is an acceptable workaround while the rest of the buggy date issues are dealt with. It would be really excellent if a corrected date format could be linked to the user's "region", too, and turned OFF if not needed. The default region date formats (e.g. yyyy.mm.dd) are often wrong, but the user has no control.

Posted by O'Reilly on December 03, 2008 at 10:22 PM CET #