Re: [Libreoffice-ux-advise] Merging Calc's label range functionality with named range.
On 07/25/2013 05:57 AM, pierre-yves.sa...@laposte.net wrote:
Hello All
Message du 23/07/13 19:46
And the original goal of my post was to figure out whether there are
people who use it, and if yes, what proportion of users (roughly), and
whether or not their use cases could be possibly fulfilled by either
named ranges or database ranges. Somehow I'm not getting any feedback
on that front.
I do user support and training for (thirty) years.
I've never met one user of this feature.
Ok. Thanks a lot for providing a data point. This helps.
However, and this goes against the opinions already given,
I found that the automatic find label option *is* used.
which really bothers me. We should at the very least turn this off by
default, and work toward deprecating this in the future (as Eike also
pointed out).
Any objection to that? Anyone?
Two concrete use cases (where the find label option has an advantage
over named ranges):
1. Managing the expansion of the range.
The formula =SUM('Sales'), where 'Sales' is the header column,
will update if you add amounts. To achieve the same result with
a named range you must either use a dynamic name (calculated)
or plan ahead more than is actually filled range.
Not currently, but the named range can be expanded to add that capability.
Having said that, the expansion of a range sounds more fit for a
database range than a named range. I'm now more leaning toward database
range as a possible replacement for the labeled range feature.
2. Adaptation of References
A table with two columns: purchases (column A) and sales (column B)
C1 =SUM('Purchase')
Copy C1 to D1 provides automatically =SUM('Sales') in D1
Good point. If we don't do this currently with named or database
ranges, we can add this capability to cover this use case.
This can not be obtained directly if Purchase is a named range
(and if the find label option is deleted/disabled).
Probably not. But if/when we implement enhanced database range, this use
case will likely be covered.
Do not get me wrong: I do not defend at all costs to maintain
this feature. I only see it is used and benefits.
This helps, as I was also looking for the missing pieces that the
labeled range provides, so that we can cover those missing pieces in the
other existing range features by extending them. Looks like it's
plausible to extend the database range to cover these missing pieces.
Thanks a lot for your feedback.
Kohei
--
Kohei Yoshida, LibreOffice Calc hacker, SUSE.
___
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.
On 07/23/2013 07:00 AM, Eike Rathke wrote: 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 ... And the original goal of my post was to figure out whether there are people who use it, and if yes, what proportion of users (roughly), and whether or not their use cases could be possibly fulfilled by either named ranges or database ranges. Somehow I'm not getting any feedback on that front. anyhow, this is even part of ODFF, so we somehow should support it. We should somehow *handle* it during import, yes. Presence of it in the ODF spec does not automatically dictate that we should have the feature available in the UI, for run-time use. What is debatable is the automatic label lookup that IMHO should be deprecated and the default configuration setting be disabled. OK. * 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' Understood. But again, you are talking about implementation details here. I was hoping for an argument that's more usability-oriented, hence my motivation to CC it to ux-advise, and the emphasis on use case in real life. * 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. *If* there are only a few defined label ranges used per document. Such assumption (or hope) can be very fragile in reality and I tend not to make such assumption especially when spreadsheet documents tend to become very large very easily. * 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. Sure. But this is an implementation detail that's not the focus of my original post. Whether or not we could re-use the label range implementation for the enhanced database range feature is a topic for another discussion, and one that doesn't have to involve our UX experts. 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. Kohei
Re: [Libreoffice-ux-advise] Merging Calc's label range functionality with named range.
On 07/18/2013 08:09 AM, Eike Rathke wrote: 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. 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. * 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? * 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. * 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. Kohei -- Kohei Yoshida, LibreOffice Calc hacker, SUSE. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] Merging Calc's label range functionality with named range.
Hi there, 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. What the label ranges provide can be pretty much achieved by named ranges, and with named ranges you can do much much more. The UI for label ranges is very clunky, unattractive, and hard to use. Rather than trying to maintain and improve this almost duplicated functionality, we should just drop it and encourage users to use named ranges instead. Dropping this functionality would also help clean up the implementation and make it easier for us to improve the formula engine going forward. So, I would passionately love to see that happensince the presence of this functionality currently is making it harder to maintain the formula engine code, much less improve it. Excel also had similar functionality but dropped it in Excel 2007, and steered the users toward using named ranges. So, there is no concerns with regard to interoperabilityeither. Best, Kohei -- Kohei Yoshida, LibreOffice Calc hacker, SUSE. ___ 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)
On Wed, Mar 20, 2013 at 5:20 AM, Eike Rathke er...@redhat.com wrote: 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? Well, that's how it is implemented today. It's not per design but due to how this feature has evolved historically. This data provider interface was designed and put in place *before* we added this pivot cache backend. This difference actually causes additional headache, since we can't always assume that the pivot cache be populated, which ties our hands in many places in the pivot engine. 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, Yes, but to achieve that, one has to implement the *whole pivot result calc engine*. To me that's an overkill, just to avoid implementing a simple data connectivity backend. It would be much simpler to just write a data connectivity backend and re-use the database connectivity backend of the pivot table. 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. Sure. But I'm sure that could be implemented via some sort of data connectivity proxy, which to me would be much simpler than developing the entire result calc engine from scratch. Probably there'll always be _some_ use cases such a provider could have (does Excel have that? if yes then there are ...), Unless I missed something (someone could enlighten me on this), Excel only provides MS SQL connectivity which is equivalent of our database connectivity backend. 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. Sure. But to justify this enormous design constraint, I'd like to hear from the actual users / deployers about why this special data provider was needed in the first place, so that their requirement still will justify the complexity it imposes on 100% of users of pivot table, including those who don't use this data provider backend (which I imagine constitutes 99.9% of all pivot table users). Kohei ___ 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 Eike, Thanks for your reply. On Wed, Mar 13, 2013 at 4:48 PM, Eike Rathke er...@redhat.com wrote: Hi Kohei, On Tuesday, 2013-03-12 11:41:32 -0400, Kohei Yoshida wrote: I'd like to ask whether someone actually uses this Pivot Table data provider extension framework, because I'd like to remove this if nobody is using it, or only few people are using it. From what I remember that can be used to populate pivot tables with data obtained from external resources like databases. Unfortunately you'll hardly find such extensions in the wild but more within enterprises and corporate users, so determining whether it's actually used or not is nearly impossible unless someone knows who those customers are. Understood. I imagined it would be used only in such enterprise setting, by someone with enough resources to develop the major part of the pivot engine as an extension. 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. I consider the pivot cache part an implementation detail, so I'm not sure if that's what you meant by storing it in the spreadsheet... The way it is currently implemented also makes it *extremely* difficult for us to optimize the pivot table engine, because all its functionality has to go through the UNO API which forces us to do data conversion *twice* for every single transaction. That's very very expensive especially as the data size grows (and it always does). Seconded. And this to me is a considerable disadvantage on further speeding up the engine and reducing its memory usage. So, I'd *love* to get rid of this sooner rather than later, and I'd like to know whether there are people who would absolutely need this functionality, and if so why. As I said above, I believe the same functionality could be achieved via the database connectivity backend even if we remove the extension backend. I think there work needs to be done to pull the data and provide it in a form that pivot tables can actually process. It may be viable, but I'm really not familiar with pivot table topics. Yes. So, anyone who currently use this data provider extension backend would change the way the data is connected to Calc's pivot table; which will require *some* work. But, considering that developing such an extension requires a non-trivial resource (it's almost half o the whole pivot table engine), I would imagine they could spare a bit of their resource to set up database connectivity to achieve what they need... At least that's what I'm hoping. Kohei ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] Pivot Table data provider extension framework (removal possibility)
Hi there, I'd like to ask whether someone actually uses this Pivot Table data provider extension framework, because I'd like to remove this if nobody is using it, or only few people are using it. Currently, Calc's pivot table supports 4 different backends. They are: 1. cell range on sheet 2. named range on sheet 3. database (registered via database manager) 4. extension acting as a data provider. The 4th one is what I'd like to get rid of. When creating a pivot table via Data Pivot Table Create..., you'll get a dialog with these 4 choices. The 4th one, labeled External source/interface is usually disabled *unless* you have extension installed that implements all pivot table interfaces necessary to act as a data provider. These are UNO interfaces that are recently *un*-published in the 4.0 release. On this page: https://wiki.documentfoundation.org/ReleaseNotes/4.0 All UNO services/interfaces/etc starting with com.sun.star.sheet.DataPilotSource and below are the ones that are relevant for this data provider functionality. 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. The way it is currently implemented also makes it *extremely* difficult for us to optimize the pivot table engine, because all its functionality has to go through the UNO API which forces us to do data conversion *twice* for every single transaction. That's very very expensive especially as the data size grows (and it always does). So, I'd *love* to get rid of this sooner rather than later, and I'd like to know whether there are people who would absolutely need this functionality, and if so why. As I said above, I believe the same functionality could be achieved via the database connectivity backend even if we remove the extension backend. Thanks, -- Kohei Yoshida, LibreOffice hacker, Calc ___ 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 listbox in calc options pages
Hi Astron, On 12/07/2012 06:41 PM, Stefan Knorr wrote: Hi Markus, Since 4.0 we are able to use the cached values written into OOXML files to prevent a slow recalculation when opening a file. Hoewever Excel and Calc don't always give the same result for formulas so we (Eike, Kohei and me) agreed that we need to give the user a choice wether to recalculate the formulas or not. How are users supposed to know when they need it and when they don't? They aren't. Heck even we the Calc developers don't know that for sure. Ideally all formula functions generate identical results. In the real world, however, they generate slightly different results due to many factors; different algorithms used internally, binary double precision numbers rounding errors, and even some bugs in the formula function implementations (either in Calc or in Excel). And this is always a moving target as Calc and Excel both change the internal implementation of formula functions between releases. I'd assume that if users are supposed to work with the spreadsheet in LibO, they need to use the numbers that LibO generates ... It's actually a little more gray than that. I would expect the results to be pretty close enough between Excel and Calc, so in most casual use cases it shouldn't be necessary to recalculate on load every single time. This is why we've decided to cache the results to speed up the load time. But in some advanced use cases where numerical precision and tractability of the formula results is absolutely essential, this may not be good enough, hence the need to provide a choice to the user. thus, what would sound more sensible to me would be an automatic blacklisting of certain formulas whose results you know to be different in LibO than in MSO (and then recalculate everything that depends on these, of course). I'm afraid we can't do that with reasonable effort, especially when the algorithm that Excel uses is not very well defined (and is potentially a moving target). Even if we decide to do it, the data may not be reliable enough to be usable, especially over a long haul. Best, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] XML Import
On 11/26/2012 12:13 PM, Kohei Yoshida wrote: First point: I would not expect Data - XML Source for launching the XML Source dialog, because all other cases, where data are inserted, are in menu Insert (Sheet, Sheet From File, Link to External Data). The reason I put it there is that, this feature will be tied very closely to Calc's existing database range feature in the later revisions (though not in the version that will go into 4.0). Currently, you insert or modify database ranges in Data - Define Range, and I'd thought that it would make sense to place the new XML Source menu entry somewhere close, because of this reasoning. Oh yeah, there is another reason for that. Although in 4.0 this feature will only allow import, in the later revision it will also support export into XML, and I'd like those two (import and export) to be in the same submenu. In addition, once we support saving of the XML source information, that is, having the XML source information with the document, information such as the path to the original XML file as well as the mapping info, we will support refreshing of the source data. This means that the submenu will contain three entries: 1) import, 2) export and 3) refresh. We could also put this menu entry under Insert menu in 4.0 and move it to the Data menu when the export and refresh are implemented. But I don't want to move the menu entry around. BTW, I just merged the very preliminary version of this feature into master. I still would like to tweak the UI a bit (especially the tree control's behavior) and revise the icons, but you can play around with it when the next master dev build becomes available. Best, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] XML Import
Hi Alexander, On 11/24/2012 11:46 AM, Alexander Wilms wrote: Hi Kohei, here are two versions of the three icons. I'm not sure whether the blue 'lines of text' are enough to differentioate betwwen them, so I added more colorful versions: http://ubuntuone.com/31ia6eIVjbKsX3zTYbZ08b Hope that works for you Thanks a lot for your icons. They look beautiful. And I took some screenshots of what they looks like in the actual dialog: http://people.freedesktop.org/~kohei/xml-source-icons-1.png http://people.freedesktop.org/~kohei/xml-source-icons-2.png I have some feedback on the design of the icons. Firstly, I understand that they do represent the characteristics of what XML elements (recurring and non-recurring) and attributes are in the context of an XML tree (since each icon contains multiple lines representing multiple elements), but I feel that they look a bit obscured when used in the tree control. I believe they would look better if each icon only represented single, individual element. I hope this makes sense. Secondly, with this icon set, it's hard to distinguish attributes from elements, and I do want them to be visually distinguishable at first glance. Perhaps something like using a difference shape for attribute icon may achieve that effect. As far as the element and recurring element, they can look similar, yet with some subtle difference to give the user that they are different. Anyway, I'm not a designer, so perhaps there are better ways to address my concerns. I'm open for suggestions. Again, thanks for looking into this. Let me know if you have any questions and things I can clarify for. Best, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] XML Import
On 11/26/2012 12:13 PM, Kohei Yoshida wrote: The dialog needs expand/collapse tools. Yes, I agree. The only reason why it's not there is simply because I haven't figured out how to implement that in the existing tree control we have. Once we figure out how to extend our (one and only) tree control to show expand/collapse tools, we can show them there too. And I think this should be done to all tree controls globally, rather than just for the one in the XML Source dialog. That would make the maintenance easier and help keep the internal design cleaner. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] [Patch] [Feature] Gradient Fill for Cells in Calc
Hi Muthu, On Tue, Sep 11, 2012 at 3:46 AM, Muthu Subramanian K sumu...@suse.com wrote: I appreciate your listing of remaining issues. My question is that, this is apparently a work-in-progress code. Are you going to be working on the pending issues, and if yes, do you think you can make it in time for 3.7 or do you need more time? Or do you need someone else to take over? What's the overall game plan? The minor issues can be handled before 3.7. I guess the only feature is import/export to and from ods and xlsx. How important are they for an experimental feature? Is it necessary before the code is merged to master (or 3.7), please? Not for an experimental feature. But I'd still like to have *some* plan for getting the file import/export supported. If so, I would surely need help there - specifically the formats for ods. Do we have something there which we could (re)use (e.g. reuse area fill elements?). I don't know much there, unfortunately :( No one does. Someone will have to dig deeper and find out. If you are willing, great. if not, we'll need to find someone else willing to dig in. Unfortunately I'm already loaded with other things, so I won't be available for this.. :-( Having said that, there are two minor comments I'd like to make. First, I'm a bit uncomfortable with the usages of pOldSet and pNewSet in ScTabViewShell::ExecuteCellAreaDlg(). It looks to me like pNewSet will leak when the dialog returns with Cancel. Also, I'm not sure if duplicating the old value with pOldSet there is necessary. You can perhaps use boost::scoped_ptr here to prevent accidental leakage of heap-allocated objects (if you really need to allocate them on the heap). oh..I will look at this - I just used the way ExecuteCellFormatDlg() works - I could have very well missed important things there :( Thanks! Then perhaps the same issue exists in the code you modeled yours from? Fixing that would be a bonus point. ;-) Second point is that the definition of operator== for XGradient has moved from the source to the header. I personally dislike putting method definitions in the header file, so I may be biased here. But I don't see the benefit of this relocation. I would just leave it at its original location. If you look at that class - all of its members are inline (and defined in the header). Unfortunately, it seems like the library is not available to do the == test in frmitems.cxx. Since all the other members are inline and this check too was a simple return statement I chose to move it to the header. Would you prefer some other way, please? I would still leave it as-is before your change (as I said in my previous post). Thanks, Kohei ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] [Patch] [Feature] Gradient Fill for Cells in Calc
On 09/10/2012 03:56 AM, Jan Holesovsky wrote: Hi Muthu, Muthu Subramanian K píše v Po 03. 09. 2012 v 13:04 +0530: I have attached a first cut patch for the gradient fill for cells. I initially tried using only the 'Gradient' tab from the area fill dialog - but it was too tightly tied to it. On the other hand probably we might want to include the other fill styles (and other tabs in the area dialog) for cells in calc too (?). Wow - I love the screenshot, thanks so much! :-) It was your HackWeek project, wasn't it? - nice work. Pending issues (afaik): 1. Import/Export it to the ods format 2. Import/Export to xlsx format 3. Remove color tab from the format cell dialog 4. Implement 'no fill' option in area fill dialog 5. Testing: There could very well be bugs with this patch - I haven't done an extensive testing. 6. Minor (for documentation sake): Background color is set without testing if the user selected it or not. if(set) is required there. I appreciate your listing of remaining issues. My question is that, this is apparently a work-in-progress code. Are you going to be working on the pending issues, and if yes, do you think you can make it in time for 3.7 or do you need more time? Or do you need someone else to take over? What's the overall game plan? I would be really nice if somebody (both from calc and ux team) could review this patch, please? I don't feel like I should be approving the code, letting it to the Calc guys... Eike, Moggi, Kohei? :-) I can't really approve or disapprove here, since the change is mostly in areas I'm not that familiar with. I trust Muthu did his due diligence to make sure the feature works, minus the pending issues. From my POV, I would just need some prospect on how the remaining issues are to be addressed. Having said that, there are two minor comments I'd like to make. First, I'm a bit uncomfortable with the usages of pOldSet and pNewSet in ScTabViewShell::ExecuteCellAreaDlg(). It looks to me like pNewSet will leak when the dialog returns with Cancel. Also, I'm not sure if duplicating the old value with pOldSet there is necessary. You can perhaps use boost::scoped_ptr here to prevent accidental leakage of heap-allocated objects (if you really need to allocate them on the heap). Second point is that the definition of operator== for XGradient has moved from the source to the header. I personally dislike putting method definitions in the header file, so I may be biased here. But I don't see the benefit of this relocation. I would just leave it at its original location. Other than that, nothing else jumps out to me. The feature itself will be an welcome addition. I would like to see it included in the 3.7 release. Thanks, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Disabling file opening and saving in print preview mode
On 06/05/2012 11:22 AM, Kohei Yoshida wrote: The reason for disabling the close commands rather than intercepting them and translating them to just end the preview mode is because it's technically very difficult to do so because of the way we end the preview shell. I won't go into the detail here. Actually I've figured out a way to do that. Now when you select File - Close or Ctrl-W in the preview mode, it will end the preview and go back to the normal Calc window. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Disabling file opening and saving in print preview mode
On Thu, 2012-05-31 at 16:07 -0400, Kohei Yoshida wrote: That also means that I'll just have to go back and figure out what's going wrong when saving the document from the preview mode (as reported in the bug report). :-/ Ok. There is a major issue when saving a document from the preview mode I just discovered. None of the view properties that normally get saved when saved from the normal mode get saved when saved from the preview mode. The reason is, as I mentioned earlier, the preview mode is an entirely separate application from the normal Calc app, and it doesn't have access to all the view properties that the normal Calc app has. This is a major setback... I'd still like to offer a save from the preview, but fixing this will not be without technical challenges... Here, the term view properties refers to the data that get saved in the settings.xml stream in the ods archive. You can unzip a test ods and compare this xml file with one saved from the normal mode, and one saved from the preview mode. The latter is missing quite a bit of information which probably contributes to the odd behavior reported in the bug. Scratching my head... Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Disabling file opening and saving in print preview mode
On Thu, 2012-05-31 at 19:04 +0200, Stefan Knorr (Astron) wrote: → reply to list, too Hi Kohei, I noticed that we actually allow saving and loading of document in print preview mode. But to me that feels very odd. What sticks out as most odd to me is that our print preview is so incredibly cluttered (menu bar + 2 toolbars), whereas e.g. in Firefox it is very focused (just a toolbar). So, yes, I do agree with this, in general, just the Print Preview toolbar should be enough. Actually (thinking about this again), given the way our current preview window is implemented, this (i.e. remove the menu bar and the top tool bar, and only leave the preview toolbar and disable a bunch of other things) is probably the best we can offer. Anything else we try to do would end up causing lots of odd behaviors in many corners, such as bug fdo#48348. However [crazy idea], since we now have a Print dialogue that already contains a preview, might it be worth thinking about just removing the separate print preview feature and making the print preview inside the dialogue a little bigger? This is a certainly possibility too. We should keep this idea as a long-term solution. In the short-term though, doing the above would be the solution I'd choose. -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Disabling file opening and saving in print preview mode
On Thu, 2012-05-31 at 19:26 +0200, Rainer Bielefeld wrote: Kohei Yoshida schrieb: What do you think about disabling these operations while in print preview mode? Hi, My POV: I would LIKE a save (or better: close) and reopen in PP mode for some WRITER documents. Those are data sheets and small catalogs, what mostly are opened to print some pages of the document as attachment for a delivery of goods or similar. So my suggestion would have been let WRITER documents open documents in PP mode if they have been saved from PP mode, in some cases that saves some mouse clicks. Well, unfortunately we will probably have to adopt the Writer way (of never opening in PP mode) in Calc too, due to the limitation I already outlined in my other mails. The preview window needs parts of the view properties transferred from the main Calc window when it launches, and if we launch the preview window first before we initialize the view properties in the main Calc window first, we'd lose that opportunity. This may have worked okay in the past when we didn't do any clever pagination in the preview mode. But now we do more sophisticated pagination based on selected sheets, losing the proper initialization in the main Calc window would be detrimental... But that is a very low-value desire. And hopefully you'll be okay with it. Currently Writer always will open in normal view mode (or Web view), even if the document has been saved from PP mode. So we should eliminate that inconsistence by always opening documents in Normal View (or Page break preview mode, if selected), even if document has been saved from PP view. But I do not recommend to disable save as long as PP is active. That would be inconsistent compared to writer and might be worrying. Simply ignore was in PP mode when has been saved. Then I would propose disabling save in Writer too. I have enough reasons to believe that, in Calc at least, saving the document from the preview mode would never work to everyone's satisfaction. It would always leave some weird corner cases even if we fix this particular bug that Terrence reported. Kohei ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Disabling file opening and saving in print preview mode
On Thu, 2012-05-31 at 13:36 -0400, Terrence Enger wrote: There remains a question about what the program should do when the user (or system?) closes the application while a changed document is in preview mode. I think the Save/Discard dialog at this point is still highly desirable. If it is easiest to go back to the editing program and let the editing program handle it, I think that would be fine. Yup. I think we'll need to pass that on to the main Calc window and have the main window handle it, instead of having the preview window handle it in-situ. Good point. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] layout of data bars
On Mon, 2012-05-21 at 00:46 +0200, Markus Mohrhard wrote: Hey, the data bar code is now in a quite good shape so that I can focus on the smaller things. There is one thing were I have no idea which one is better. You'll find attached two versions of the same file. In the small version the data bar does not fill the whole cell while it does in the large version. Excel uses something similar to the small version. Which version do you prefer and which one is the clearest from an UX point of view? If my opinion counts, I prefer the small version (one with some spacing between the bar and the cell border). It looks better and more refined to my eye. But I can't provide any logical reasoning for my preference; it's just purely my aesthetic preference. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] calc background colors ...
On Wed, 2012-02-15 at 16:06 +, Michael Meeks wrote: Hi guys, Trawling negative user comments (as we ought to to try to improve ;-) I saw this: http://news.slashdot.org/comments.pl?sid=2671075cid=39034649 Well, they're obviously moving much faster than openoffice did. The product looks very clean, opens fast, and is mostly enjoyable to use. There's still a number of key combinations that Calc is missing (most noticeably ctrl-D to copy cell above), You mean fill down via Ctrl-D? That's been the default key binding since 3.3 and the background color tool is still horribly designed (only contains colors too dark for use as a background, and it does not remember the last chosen color). Not sure about the colors being too dark. Someone should look into that for sure. But haven't we recently landed a patch that implements the remember-the-last-color functionality? It's simple stuff like this that keeps people on Excel. Obviously some of his claims have been addressed. Which makes me wonder ... what we can do about this ? :-) Ask him to try out 3.5 would be my first choice. I'm sure he'll come up with a whole load of new reasons to stay on Excel (which is to be expected; that's what users do). :-) As for the color palette issue, I don't have a strong opinion so I'll stay away from making any feedback on that one. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] calc background colors ...
On Wed, 2012-02-15 at 11:29 -0500, Kohei Yoshida wrote: Excel appears to do this only when a single cell is selected, so it's a very limited case it should be trivially easy to implement it, I think. Implemented on master. http://cgit.freedesktop.org/libreoffice/core/commit/?id=ab0096ed68cdc08906f518d3499a8e1afc5ba80c Turns out that you could also select multiple cells and copy multiple cells down in one step i.e. select A2:B2 and ctrl-D to copy A1:B1 down. I've implemented that as well. The same applies for the other 3 directions. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] calc background colors ...
On Wed, 2012-02-15 at 11:16 -0500, Kohei Yoshida wrote: and the background color tool is still horribly designed (only contains colors too dark for use as a background, and it does not remember the last chosen color). But haven't we recently landed a patch that implements the remember-the-last-color functionality? Yup. We have. This one is already implemented on master as well. So, the only issue still remaining is the color palette. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Input bar UX
On Mon, 2011-12-12 at 15:24 +, Noel Power wrote: On 12/12/11 14:00, Jan Holesovsky wrote: - jumping Name Box (and actually the icons too, but not that much) when you switch from and to large input bar This annoys me too, there is a hack in the toolbar code to prevent it from doing what toolbars want to do which is display items in the middle of the bar, the behaviour you see is the side-affect of this hack. I can try and do it better, then again myself an Kohei discussed maybe subverting the toolbar layout ( or lackof ) in a future implementation step, I mean to return to this in anycase but probably this is not my #1 to fix at the moment Yes. So this is a technical limitation of using the ToolBox class from vcl to manage the horizontal layout of the controls (inherited from the old implementation). ToolBox can only manage controls horizontally, but we have little control over how it manages them vertically. Noel and I discussed this, and the plan is to create our own container Window to replace ToolBox in order to have more control over the vertical placement of the child controls, to fix issues like this. But since doing that would be quite invasive, we may have to forgo that for 3.5 and wait until 3.6. It's up to Noel. - behavior of Ctrl-Enter - when in single line mode, and you hit that, it should automatically switch to the large input bar - now it just lets you with an empty line, and you see the entire picture only in the sheet personally I think it is reasonable behaviour, after you hit cntrl-enter the inputbar still displays your current edit. Also, you can scroll through the lines with the mouse. Plus the user does decide to display one or (more) lines ( via the collapsed/expand button ). Even if you expand the toolbar via switching to multiline mode you can also easily exceed the display space again. Worth noting too that switching between multiline and single line mode will resize the bar to the last expanded size which could be as little as 2 lines wide so you could exceed that vertical limit very quickly. So.. expanding might only give you very temporary relief before you need to expand the bar even more ( via dragging with the mouse ). This doesn't make auto switching that sensible ( unless there is some extra heuristics there, then of course probably people will be confused as to why sometimes it autoexpands and sometimes not ;-) ) Yeah. To me, the way it behaves currently may not be perfect, but is reasonable it was a conscious decision that we (Anurag and I) made before Noel took over, based on the technicality (it makes the implementation simpler) and the way our competitor behaves. Of course, if there is room for improvement I'm all for it, but different people may see different optimal behavior for this, so it would be good to have a good, detailed analysis from the UX side before making any changes. - behavior of the Bold / Italics / etc. buttons - when entering text in the large input bar, and hit the Bold etc. buttons (that are just above that), the formatting is shown only in the sheet, but not in the input bar (is that actually expected due to some implementation limitations?) again this is afaiks intentional and matches excel behaviour, there is most likely some real reason why we don't support that ( probably because inputbar is mostly for formulae and not writing prose ) Maybe Kohei might know better AFAIK there is no real reason except that we simply inherited this behavior from the old implementation. Excel has the same limitation interestingly, but that has nothing to do with our decision (or lack thereof). There may be a real reason why this limitation existed, but I'm not aware of that at the moment. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ 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
On Fri, 2011-11-04 at 22:10 +0100, Christoph Noack wrote: Hi Kohei, all! A small disclaimer: currently there are so many topics at the same time, that I have difficulties to follow all the mails ... so please bear with me if I missed a comment from your side. Am Donnerstag, den 03.11.2011, 12:01 -0400 schrieb Kohei Yoshida: Hi Christoph, On Thu, 2011-11-03 at 08:06 +0100, Christoph Noack wrote: I assumed that because also Excel only provides to update one name or range at a time. Ah! Well, this needs a bit more explanation, I suppose. In short, this assumption of yours is not entirely correct. Thanks for the explanation below ... I wanted to have a look at Excel 2007 at work, since I don't have a version at home. So I have to rely on your description, my brain and the documentation in the web. Unfortunately, the information from the different sources seems to differ ;-) Just to remember: The original question was, whether people do experience bad performance, if only one range name is changed at once. You told me yes, so we need to offer a change multiply names, then apply the changes. I've asked why Excel can do this, since I understand their implementation that way. So here we go ... In Excel 2007 and up, the Name Manager dialog is in fact modal, and it launches a separate sub dialog to allow editing of individual names one at a time. An example of the Excel 2010 manage names dialog can be seen here: http://media.wiley.com/Lux/10/209010.image0.jpg I understand it the following way ... adding / editing a single entry launches a separate window that needs confirmation. It exists a shortcut to change the expression - but that also needs confirmation via the checkmark button. But, the manage names dialog itself is non-modal, since it generally seems to allow working with the document. Only one exception: You cannot use the Name Manager dialog box while you are changing the contents of the cell. according: http://office.microsoft.com/en-us/excel-help/define-and-use-names-in-formulas-HA010147120.aspx So, in general, the name manager is non-modal. Whether it updates the name directly in the model directly when it's updated in the dialog is unknown (since we don't know what Excel does internally), but because the main Name Manager dialog is modal, it won't perform re-calculation until that dialog is dismissed. What this means is that Excel's name manager dialog only performs re-calculation *once* even when you modify two or more names as long as you don't dismiss the main dialog between the editing of the names. If I understand the Excel help well enough, it works differently. The documentation (see link above) mentions several times: The Close button only closes the Name Manager dialog box. It is not required to commit changes that have already been made. This only indicates that Excel updates the names directly in the model from the dialog. But that alone has nothing to do with the modality of the dialog, and when the re-calculation occurs, which is the heart of this performance discussion. I already indicated that this may be what Excel does in my previous post, and based on what the above help says that's indeed what Excel seems to do. However, I also indicated that, even if we decide to update the name directly in the model (which basically removes the possibility of canceling the changes, but I guess that's the trend we are following), we could still turn off auto re-calc temporarily before launching the dialog, then turning it back on after dismissing the dialog, to hold of re-calculation until the dialog is dismissed, as long as the dialog is modal. And, since Excel's dialog is modal, Excel can do exactly that, to hold of re-calc until the dialog is closed. To me it seems that all the actions within the manage names dialog do handle one change per time - whether it is a modal dialog, or the expression field. That was my starting point to ask why Excel seems to perform well enough for such a interaction design. Again, what we are primarily focusing on in this discussion is when to perform the re-calculation, not when to modify the names in the model. These two are closely related, but they are not the same thing. Excel updates the model one change at a time, but it doesn't perform re-calculation at every name update; it performs it only when the dialog is dismissed, which happens only once. The only reason it can do that is because the dialog is modal. I hope that makes sense. And Christoph, I sincerely hope that you will find the opportunity to play with Excel 2007 or 2010 to see what this functionality works in person, and see when and how often Excel performs re-calculation in relation to name updates. Otherwise we could go back and forth with this endless see-saw. All the best, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc
