Sorting table breaks proper insert of new rows

[Lisa Ruby]

I am seeing this issue in the Windows 0.63 version of Zim-Wiki. While editing a table, clicking the arrows to sort by any of the columns seems to break proper inserting of new rows. I have a table with two columns and multiple rows. When I try to insert a new row into a table after clicking the sort arrows, the new row always gets inserted at the top of the table and cannot be moved down. Closing and reopening Zim-Wiki resolves the problem.

[Pl (plprgt)]

I want to add some points.
This happens in Zim 0.65 too. To insert new rows or change their position are used functions like 'swap', 'insert_after' in 'tableeditor.py'. In pyGTK docs it is written about these functions: “Note that this method only works with unsorted stores.” And: “Once a sort column ID has been set on a gtk.TreeModel implementing the gtk.TreeSortable interface it cannot be returned to the original unsorted state.” So it seems that if sorting remains as is than other approaches should be used to change position of rows.
Currently a workaround is reloading a page with tables (via pressing Ctrl-R, or moving to any other page and then coming back), after that it is again possible to change row position until sorting is pressed.

[Jaap Karssenberg (jaap.karssenberg)]

Hmm, I see the problem, although I can't find the doc you are referring to.

In addition, should there be a way to reload the table to unsorted state ?

-- Jaap

On Wed, Dec 23, 2015 at 5:26 PM, Pl <email address hidden> wrote:

> I want to add some points.
> This happens in Zim 0.65 too. To insert new rows or change their position
> are used functions like 'swap', 'insert_after' in 'tableeditor.py'. In
> pyGTK docs it is written about these functions: “Note that this method only
> works with unsorted stores.” And: “Once a sort column ID has been set on a
> gtk.TreeModel implementing the gtk.TreeSortable interface it cannot be
> returned to the original unsorted state.” So it seems that if sorting
> remains as is than other approaches should be used to change position of
> rows.
> Currently a workaround is reloading a page with tables (via pressing
> Ctrl-R, or moving to any other page and then coming back), after that it is
> again possible to change row position until sorting is pressed.
>
> --
> You received this bug notification because you are subscribed to Zim.
> https://bugs.launchpad.net/bugs/1515079
>
> Title:
> Sorting table breaks proper insert of new rows
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zim/+bug/1515079/+subscriptions
>

[Pl (plprgt)]

Sorry, should have added links to docs.
So
http://www.pygtk.org/pygtk2reference/class-gtkliststore.html#method-gtkliststore--swap
and
http://www.pygtk.org/pygtk2reference/class-gtktreesortable.html
(use search to find quotes on the pages).

I may be wrong but as I understand after clicking on column name the only way to disable sorting is by recreating a table. Maybe it is better to completely disable sorting by column names clicking and make sorting (by gtk.ListStore.reorder) via an option in table properties or popup menu. What I like in this approach is that otherwise it is easy to accidentally press column name and lose your table's initial order without undo option.

[Tobias Haupenthal (beutlin)]

Okay, now I understand the issue:

Request is for disable sorting after enabling it without reloading the page.
You like to go back to unsorted table mode, in which rows can manually moved up/down.

[Pl (plprgt)]

Sorry, I made a mistake. In docs it is written that 'move_after' function can't work with sorted stores, but nothing is written about 'insert_after' (with swap function it is correct – it works only with unsorted stores).

I came up with some solution. It seems to be impossible to return to unsorted state (without reloading) so I created default sorting (which in fact doesn't sort). This solved the situation with 'insert_after' function, but 'swap' still didn't work (sorting is not disabled – it is just set to default state). Therefore I changed rows manually by changing their values. My solution is in patch (compared to rev. 814) – it seems to work, though there may be better ways to solve this.