I have tried the software “LibreOffice Calc 6.2.4.2-821.3” (Build-ID: 20(Build:2)) out again. The dialogue “pivot table layout” contains the list control “data fields” where entries are displayed with the items “field name” and “computation” concatenated by a dash so far. I would find it more helpful to present these items in a corresponding table control because such data organisation can provide nicer navigation functionality with separate columns.
Markus, please make some mockup for your suggest
(In reply to Roman Kuznetsov from comment #1) Would you like to replace a questionable list user interface for the data field selection by a nicer table widget in the dialogue “pivot table layout”? https://help.libreoffice.org/6.2/en-US/text/scalc/01/12090102.html https://developer.gnome.org/gtk3/stable/GtkTable.html#GtkTable.description https://doc.qt.io/qt-5/qtableview.html#details
(In reply to Markus Elfring from comment #2) > (In reply to Roman Kuznetsov from comment #1) > > Would you like to replace a questionable list user interface for the data > field selection by a nicer table widget in the dialogue “pivot table layout”? > https://help.libreoffice.org/6.2/en-US/text/scalc/01/12090102.html > https://developer.gnome.org/gtk3/stable/GtkTable.html#GtkTable.description > https://doc.qt.io/qt-5/qtableview.html#details I wouldn't, bad idea Mike, Eike, Heiko, any opinions?
(In reply to Roman Kuznetsov from comment #3) Do you find an other information source easier to follow? https://developer.gnome.org/gtkmm-tutorial/stable/sec-treeview-examples.html.en#treeview-popup-menu-example
(In reply to Markus Elfring from comment #0) > The dialogue “pivot table layout” contains the list control “data fields” > where entries are displayed with the items “field name” and “computation” > concatenated by a dash so far. You talk about the "Data Fields" dropdown at the pivot table dialog showing up on creation and when you click Edit Layout, right? And there is/are entry/ies "Sum - Foo" and "Count - Bar" (double click to get a list of functions to switch to "Average - Foo" and "Min - Bar"). Don't see much benefit from switching to a table or any other control with columns since you cannot interact with the source column (like changing "Count - Bar" to "Count - Baz"). Do you run into any trouble?
(In reply to Heiko Tietze from comment #5) I would appreciate to sort field names separately from the selected computations. Will any more attributes become relevant for a table widget?
(In reply to Markus Elfring from comment #6) > Will any more attributes become relevant for a table widget? Hard to imagine. Eike, any opinion on having a two column control there?
In Data Fields the function is a property of the field, so "sort field names separately from the selected computations" does not make sense. IMHO displaying fields and functions in a two column table may have a benefit of a somewhat cleaner layout within that list, but might be more confusing in the overall look of the dialog, also because it would leave the impression the two columns of one row would be individual items. Note that the pivot table layout dialog is highly customised with all its drag&drop across listbox widgets functionality; changing that probably wouldn't just be "choose another widget type". Drag&Drop should always affect the entire row, both columns, the Data Field Function dialog probably be raised with a click anywhere on the row, not just the function column. When at it, we maybe could even display the Displayed Value property, but then again that might be totally confusing, I don't know. I'm lowering priority, but if someone wants to wrap his/her head around this, well..
Given we accept the sort request, wouldn't a simple context menu be sufficient? I wouldnt add another control there and the table widget is not well suited.
(In reply to Eike Rathke from comment #8) > In Data Fields the function is a property of the field, so "sort field names > separately from the selected computations" does not make sense. My user interface expectations can be different from the currently available data model. > IMHO displaying fields and functions in a two column table may have a benefit of > a somewhat cleaner layout within that list, Thanks that you can follow a view in such a direction. > but might be more confusing in the overall look of the dialog, I wonder about your concerns about confusion here. > also because it would leave the impression the two columns of one row > would be individual items. How would you get to such an interpretation for the usage of rows? > Note that the pivot table layout dialog is highly customised with all its > drag&drop across listbox widgets functionality; changing that probably > wouldn't just be "choose another widget type". Would you like to offer switchable data views? > Drag&Drop should always affect the entire row, both columns, the Data Field Function dialog probably > be raised with a click anywhere on the row, not just the function column. I would agree to such an expectation. (In reply to Heiko Tietze from comment #9) An improved context menu can be combined also with a list and/or table view, can't it?
(In reply to Markus Elfring from comment #10) > (In reply to Eike Rathke from comment #8) > > but might be more confusing in the overall look of the dialog, > > I wonder about your concerns about confusion here. The dialog is already quite complex. Adding a table instead of the single area right in the middle of the dialog draws attention and focus on something that usually contains only one to a few entries. As for a new pivot table it's starting with empty table there doesn't make things better. > > also because it would leave the impression the two columns of one row > > would be individual items. > > How would you get to such an interpretation for the usage of rows? Because a table separates items into columns. > > Note that the pivot table layout dialog is highly customised with all its > > drag&drop across listbox widgets functionality; changing that probably > > wouldn't just be "choose another widget type". > > Would you like to offer switchable data views? What? No, I was talking of implementation. Someone would have to do that, it doesn't just arrive out of thin air.