[Libreoffice-ux-advise] LibreOffice Conference PGP Keysigning Party
Hi, If you plan to attend the LibreOffice conference and want to take part at the PGP Keysigning party (KSP) to strengthen the web of trust and meet each key holder face to face, it's only two more days time to submit your key to the libo2014.keysigning.ch server, i.e. gpg --keyserver libo2014.keysigning.ch --send-key 0xYOURKEYID Don't forget to download the list of participants on Sunday, checksum it per its instructions and print it and take the printout with you. All glory details are available at http://conference.libreoffice.org/2014/events/ksp-keysigning-party/ Happy keysigning! Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Care about Free Software, support the FSFE https://fsfe.org/support/?erack pgpwm2wnZ4Td6.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Merging Calc's label range functionality with named range.
Hi Kohei, On Tuesday, 2013-07-23 13:47:08 -0400, Kohei Yoshida wrote: Of course it doesn't matter where we actually stick the defined label in, having them as part of the database range probably is best because we usually can derive it from the top-row of the database range (don't know currently if Excel allows more than one row for those Table labels, they did a very awkward thing with their labels back then). Noted. Perhaps it was that awkward-ness that prompted them to drop this feature in 2007? I'm just guessing. Might be one of the reasons (that awkward feature btw was called Stacked Column Labels, we never implemented that in its implications though). I guess another reason is the introduction of the XML based file format, they probably encountered similar problems we do. The automatic lookup depends on the actual current content of the document, one can quite easily generate a document using automatic label lookup that when saved and reloaded again the new lookup actually matches a different cell due to a nearer cell having the matching content. That was no problem in binary formats where formulas didn't have to be recompiled. Of course issues with editing such a formula were also present back then. Sad that MS introduced it and we had to follow :-/ Having had to implement the space operator for intersection in this specific case didn't make things better and already drove me nuts by itself ;-) Really, space operator, wtf?!? (yes Excel intersections always work that way) Remember how the whole story was advertised? Natural Language Formulas ... rant off Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A For key transition see http://erack.de/key-transition-2013-01-10.txt.asc Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpDoQp1u3nce.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Merging Calc's label range functionality with named range.
Hi Kohei, On Thursday, 2013-07-18 08:25:45 -0400, Kohei Yoshida wrote: * The actual label name displayed is taken from a cell's content, formula expressions using a label automatically change their display label names whenever that cell content is changed. * This is not possible with named ranges. Sure. But is this *that* important to users? To me the whole label range implementation is such a duplicate functionality for very little marginal difference, and I'm not really sure if that difference even matters. For those who use it it probably is important ... anyhow, this is even part of ODFF, so we somehow should support it. What is debatable is the automatic label lookup that IMHO should be deprecated and the default configuration setting be disabled. * One label names exactly one row or one column, expressions or multi-column/row ranges are not possible. * The named expressions dialog could restrict that though. I don't see how that restriction could be useful. You can define one column / one row only named ranges (or database ranges for that matter). Is there a use case where having this restriction is useful in real life? It is needed for the intersection of row and column labels, that works only with vectors, e.g. ='Sales' 'Hamburg' * The label name can include spaces and other arbitrary characters that in a formula expression would have special meanings, using such a name in an expression is possible by enclosing the entire label name in single quotes. A label name can even be a string that otherwise would be a cell reference. Yes. And the fact that this can be a string is actually very scary to me. This potentially makes tracking references very difficult without sacrificing performance. Dropping it would enable us to optimize it further. The performance bottleneck is the automatic label thing where the sheet's content is searched for a string; searching just a few defined label ranges (if any) doesn't make much difference compared to named ranges. * A named range currently has to consist of alphanumeric+underscore characters and can't resemble a cell reference. * ODFF does provide means to store usage of such non-simple names though with $$SingleQuoted but we need to implement that in the formula compiler (anyway), see http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1017964_715980110 Furthermore we probably could use exactly the Label functionality for the GSoC Enhanced Database Ranges Table feature when it comes to in-Table formula expressions adressing the Table's rows or columns. Actually it would be necessary to support identical label names for different Tables (ranges) within one sheet, again this is not possible with named ranges. I'd rather we extend the database range code to support these missing bits rather than piggybacking on top of the label range code. I don't see it as a reason why we need to keep label range. I meant the special Excel cell formula syntax for formulas in cells of a Table that address rows/columns/intersections of the Table by their header names. That is very similar to defined labels compiler/interpreter-wise. Of course it doesn't matter where we actually stick the defined label in, having them as part of the database range probably is best because we usually can derive it from the top-row of the database range (don't know currently if Excel allows more than one row for those Table labels, they did a very awkward thing with their labels back then). Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A For key transition see http://erack.de/key-transition-2013-01-10.txt.asc Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpqv2sFvvKb0.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Merging Calc's label range functionality with named range.
Hi Kohei, On Wednesday, 2013-07-17 20:29:06 -0400, Kohei Yoshida wrote: I'd like to merge Calc's label range functionality (which you can find in the menu at Insert - Names - Labels) with named range functionality. The named range functionality is found at Insert - Names - Define/Manage/Insert. Also, the Create menu item in the same menu sub-tree is also a part of the named range functionality.Here, what I basically mean by merging is to remove this functionality and provide some rudimentary mapping to the named range when importing legacy documents that use this functionality. As I see it the Label functionality currently can't be replaced by named expressions (ranges): * The actual label name displayed is taken from a cell's content, formula expressions using a label automatically change their display label names whenever that cell content is changed. * This is not possible with named ranges. * One label names exactly one row or one column, expressions or multi-column/row ranges are not possible. * The named expressions dialog could restrict that though. * The label name can include spaces and other arbitrary characters that in a formula expression would have special meanings, using such a name in an expression is possible by enclosing the entire label name in single quotes. A label name can even be a string that otherwise would be a cell reference. * A named range currently has to consist of alphanumeric+underscore characters and can't resemble a cell reference. * ODFF does provide means to store usage of such non-simple names though with $$SingleQuoted but we need to implement that in the formula compiler (anyway), see http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1017964_715980110 Furthermore we probably could use exactly the Label functionality for the GSoC Enhanced Database Ranges Table feature when it comes to in-Table formula expressions adressing the Table's rows or columns. Actually it would be necessary to support identical label names for different Tables (ranges) within one sheet, again this is not possible with named ranges. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A For key transition see http://erack.de/key-transition-2013-01-10.txt.asc Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpF5hhvAYGF4.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Pivot Table data provider extension framework (removal possibility)
Hi Kohei, On Thursday, 2013-03-14 09:26:55 -0400, Kohei Yoshida wrote: I believe the same functionality can be achieve via database connectivity, by having such external data provider register as a database, and use it to act as a data provider for pivot tables. So, I don't see a reason why we need to keep this as a separate data source category. IMHO the advantage of the data provider is that the actual data does not have to reside in the spreadsheet, allowing for massive amounts of data records but providing only the information necessary for the pivot table. This maybe could be accomplished as well using a registered data source, but currently we have no means to pull the data without actually storing it in the spreadsheet for further processing. Or isn't that the case? Well, that would depend on what you actually mean by storing (the data) in the spreadsheet. When pulling data via database connectivity, we don't actually copy the data in the spreadsheet document, but generate the pivot table output directly from it. But we *do* first populate the pivot cache from the database internally, so a copy of the data will sit in memory while the document is open. That's my bad then. I assumed the data was stored in a DB range. Is that different with the data provider, i.e. does it not need to copy all data to populate the pivot cache with an interface to directly populate the layouted pivot table? Other advantages a data provider could have are a) be able to collect data from various e.g. remote sources that a simple data connection could not provide, and b) access data in means not possible with database connectivity, for example if the user shall be restricted to a subset of a database or not be able to query using SQL statements. Probably there'll always be _some_ use cases such a provider could have (does Excel have that? if yes then there are ...), so if it's ripped out maybe offering a new interface adapted to the new data types and structures that sits on top of the engine instead of being part of it would be good. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpkruy73KUFk.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Possible change of Calc option : Expand references when new columns/rows are .. ?
Hi Cor, On Thursday, 2013-03-14 11:25:43 +0100, Cor Nouws wrote: Working with users, I quite often have the impression that it's wrong that the setting Tools Options Calc General Expand references when new columns/rows are inserted is set to OFF by default. Objections to change that to ON ? It may have unwanted effects, most users probably are not aware that every (!) expression that references an adjacent range would have that range extended and suddenly calculate differently, probably even silently. Those users who are aware can easily change that option. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpW_XARUFtMn.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Manage Names Dialog hit master
Hi Markus, On Wednesday, 2011-12-07 14:04:38 +0100, Markus Mohrhard wrote: with a thousand range names and we now open in less than ten seconds while we needed more than 30 seconds with my old implementation. What's the time needed with the old dialog? I did not test it there but we will need more time. The old dialog just added the name to a list and we now need to create an entry from name and scope. The formula calculation is only done for visible cells. I think 1000 range names are already an extreme example and since it works quite nice there we can use this approach. Well, I've seen corporate documents with more names.. 10 seconds for 1000 names sounds quite much to me. Probably worth a callgrind. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpMmOk8WL9gn.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] new range name dialog proposal
Hi, Let me chime in late on this.. On Monday, 2011-10-24 23:28:09 +0200, Christoph Noack wrote: As far as I know, it is currently not possible to know the characters in advance, because the valid characters are influenced by localization settings and some other stuff. We may only know that something is wrong - any input has to be evaluated by the expression parser. I think I already implemented somenthing in this direction. I think the Add and the modify button are only enabled if the name is valid. I still think that allowing all characters and showing a warning that some characters are not allowed is better than too much magic that nobody understands. Do we know the characters being not allowed in advance? In my statement above, I guessed we don't know them ... that was my understanding in Munich. The allowed characters are defined in ODF OpenFormula 5.11 Named Expressions http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1017964_715980110 with the 'Identifier' EBNF and actually do not depend on localization or separators used. However, showing a list of characters that are not allowed is way out of the possible, as it would encompass hundreds (or thousands?) control characters and separators of the Unicode range. Provide a positive list similar to the EBNF definition (but just saying Allowed are letters, digits and underscore and the name must not represent a cell address or some such for simplicity), or/and dynamically display the first invalid character encountered. Invalid entries in the expression line are much harder to detect. I think these errors can only be detected if we compile the formula. How long does that take usually / worst-case? (just curious, I need to learn some new aspects) I think this was already mentioned elsewhere, but in case it was not: just compiling the expression for syntactical correctness isn't problematic, we already do that. Eike P.S. @all: please don't Cc my *@erack.de accounts on LibO topics anymore, use er...@redhat.com instead so I get all LibO related mails bundled on one account, thanks. -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgp3ZuB8YEuxF.pgp Description: PGP signature ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
