[Request] Reorder Index (tree) Items

[Dennis Rasey]

I'm not sure if this is possible, or goes against the concept of an "index", but I'd love to be able to drag & reorder items (pages) in the "Index" (i.e. reorder the "tree" Index items).

I often have "sub-pages" that would make more sense ordered other then alphabetically. (for example, a ToDo list for each day of the week, would like this ordered by day or week).

Is this possible?

Thanks,
Dennis

[Jaap Karssenberg (jaap.karssenberg)]

For this feature there are a lot of technical details to decide. One is how to store the page sequence, another is how to toggle in the interface between alphabetic sorting and custom order.

One way to do this would be to always have custom sequence (new pages go to the bottom of the list) and a menu item for sorting explicitly. But may be less manageable for large sets of notes.

Of course the easy work around is to start the page name with a number, but that does not allow easy re-ordering and makes linking less obvious.

Further plan needed for implementation details.

[dotancohen (dotancohen)]

I would suggest for each page an exclusive Order Vector which is stored but not shown to the end user. The vector would hold the position of the page in the hierarchy, like this:

Weeks
-- Sunday
-- Monday
-- Tuesday
Months
-- January
-- February
Earth
-- Europe
----- Belgium
----- Germany
-- Asia
----- China
----- Korea
-- Africa

So Months would be vector (2), February would be vector (2,2), and Korea would be vector (3,2,1). This is assuming starting count from 1. The reason that I did not start counting from 0 will soon become obvious.

Now lets say that the user drags a page to a new place. The order of events would be like this:
1) The page's vector becomes (0)
2) The other pages in the same hierarchy level will have their vectors changed accordingly. That is, if a note who's vector is (x, y, z) is being moved then all notes (x, y, A>z) will have their value A--. Note that vector (x, y, a>Z, m) may also exist, and in this case m would remain unchanged.
3) The user points to the place in the hierarchy where the note should be placed. A process similar to step 2 takes place in reverse, making room for the new vector.
4) The note being moved has it's vector updated to the new location.

Operations that change the order of the notes (alphabetically, chronologically, or otherwise) will work on the vectors.

[Jaap Karssenberg (jaap.karssenberg)]

This how the GUI widget would handle re-order, we do not need to think about that, Gtk implements this.

My questions are:
* How to store this sequence in the directory structure (caching is obvious, but cache should not be main storage)
* When sorting alphabetically do we recurs or do we need to set manually per namespace ?
* If we want to have a setting per namespace, where do we store these settings ?
* Where to put new notes append or prepend ?

[dotancohen (dotancohen)]

> How to store this sequence in the directory structure (caching is
> obvious, but cache should not be main storage)

I suppose that the info could be either stored in a comment in the page itself or in a database. Both approaches have their advantages and weaknesses. Database is faster and allows for future use of the database for other purposes (Zim will bump into this time and again). However, it adds a rather large dependency to Zim. Storing in a comment in the page takes advantage of the facilities that Zim already has. And I do not think that speed will be much of a concern as it is not a primary function of the application (a short delay when moving a page is acceptable as users generally do not move pages as part of a normal workflow).

> When sorting alphabetically do we recurs or do we need to set
> manually per namespace ?

I come from the KDE school, where the user would set this via an option :)
However, by default (and if there is no option) then I think that recursive sorting is a potential dataloss situation, so I would avoid it. HOWEVER:

However, if the user could choose [alphabetical|chronological|custom] sorting and the custom sorting order were saved when the user switches to a different sorting, then I would say to go recursive. Recursive is a bit more intuitive and if the user can configure each sub namespace to his liking (and the custom setting is not lost when the user switches to a different sorting), that would be the best solution.

>If we want to have a setting per namespace, where do we store
> these settings ?

In the top-level page of that namespace (I don't like this)? In a database (I said we'd see this again)? In a hidden config file (probably the best solution)?

> Where to put new notes append or prepend ?

Append. This is how other GTK applications do it. Try dragging a tab to a bookmark folder in Firefox, it is appended to the list of bookmarks.

[Bob (bobhof1)]

A slightly different approach to this problem:

At present pages sort themselves alphabetically. It would be very useful to have an option in the preferences, which would allow to chose to sort them in ascending or descending order. This would also determine, where new notes go.
An additional useful option would be to leave them unsorted (i.e. to leave them, wherever the user creates them or drags them).

[stefan.kamien (stefan-kamien)]

It wil be very good if there will be possible to manually reorder nodes/pages in index.

[Christoph Zwerschke (cito)]

Maybe the ordering could be stored in the individual pages by adding <link rel="prev" href="..."> and/or <link rel="next" href="..."> tags to the individual pages?

[Mark Edgington (edgimar)]

Perhaps it could be useful to examine how page order is stored in the Keepnote program (http://keepnote.org/), which is similar to Zim in terms of how data is stored in a directory tree. Keepnote allows manual re-ordering of its index.

[Trish (trish-y)]

If not drag and drop like KeepNote, referenced above, or CherryTree, then what about using date to provide alternate index sorts to alphabetical ?

Within each namespaced item, there's already 'Creation-Date', though more useful and malleable would be 'Last-Updated-Date'.

It could be set as an additional tab view sort of the Index following or preceding 'Tags'. Eg. 'Latest'