history management

[pepdiz]

Currently every time you issue the command browse to widget .help with a filename, a new filename is added to history even when it's the same file:

$help browse shtmlview.html
history: C:/Users/Downloads/shtmlview/shtmlview.html

$help browse shtmlview.html
history: C:/Users/Downloads/shtmlview/shtmlview.html C:/Users/Downloads/shtmlview/shtmlview.html

$help browse shtmlview.html
history: C:/Users/Downloads/shtmlview/shtmlview.html C:/Users/Downloads/shtmlview/shtmlview.html C:/Users/Downloads/shtmlview/shtmlview.html

Even when this is debatable, for example because you want to track the opened files, I think it would be better to check if the file is already in the history stack and only add it if not already present.

[mittelmark]

That should be fixed now in the repository, if the "next" file is the same it will be not added to the history.

but
$help browse test1.html
$help browse test2.html
$help browse test1.html

would still give
test1.html test2.html test1.html

as this is just the browse or click and browse history ...

[pepdiz]

In fact more attention should be applied to the history management, since you are saving not only files but also fragments it is a bit more complicate to decide when a history item is duplicated, if you have in history:

{ c:/file1.html c:/file1.html#first c:/file1.html#second }

then you have three different history items but only one file. Since you want to track the history movements you need to keep them all, you have to decide if you want to save the real movement done by the user, i.e:

{ c:/file1.html c:/file1.html#first c:/file1.html#second c:/file1.html#first c:/file1.html#second c:/file1.html#first }

indicating the user was jumping back and forth over fragments first and second, or if you want to track the distinct history when for the same situation describe before your history will be:

{ c:/file1.html c:/file1.html#first c:/file1.html#second }

Since you are reading the file every time you visit it, I think it would be better the last option, so what I do is check if string is already in history before adding it, so if my history is:

{ c:/file1.html c:/file1.html#first c:/file1.html#second }

and I browse file2.html I get a new history:

{ c:/file1.html c:/file1.html#first c:/file1.html#second c:/file2.html }

but if now I browse c:/file1.html (or even c:/file1.html#first , if possible) I won't add it to the history because it's already there and so my history continue being:

{ c:/file1.html c:/file1.html#first c:/file1.html#second c:/file2.html }

Another problem due to handle of fragments is where to place new history items:

• an option always appending at the end of the history list, this is probably the expected behaviour for new files opened with browse command, but maybe not so good for fragments open from a file in certain position in history
• another option is inserting always after current position in history, probably this fits better in all situations but I think creates a weird history sequence
• and final option is follow the internet browsers, where movings in history are allowed only in an inmutable history, as soon as you open a new file, you loose forward history, only preserving back history from current positon, and forward from current is only the new file.

[pepdiz]

Also I think there's a problem of history mangling, after open several files and fragments, I end up with movement buttons in toolbar not accurate, for example I have close button disabled when I have one file in the browser or have forward button enabled whe I have only one file in history... more exahustive testing is required to find all cases.

[pepdiz]

interesting features to implement:

• to have the history accessible, maybe with a combobox or list, in a way you can dropdown a list with all items and history and click on what you want to fast moving rather than going back back back back back for example
• status line indicating the history from home to current, maybe a line below toolbar like:

home >> file1.html >> file1.html#fragmentA

(assuming we're currently viewing the file1.html#fragmentA in the browser)

consider it a ToDo ;-)

[mittelmark]

There is now a widget option -historycombo (default: false) which can be set to true at widget creation, then you get a ttk::combobox with history where you can directly pick a link.

However, it is important to not blow up the widget with too many more or less specific features, it should just provide the basic functionality to browse a set of HTML or Markdown files. However it should offer methods and options to extend the functionality by the user/developer. That for instance is the browsecmd option thought for, you, as a developer, can keep track of all visited files and anchor links in the script given to that option. To simplify this even more, I now added as well two public methods getFiles and getHistory which can be used to retrieve this information directly. BTW: The functionality you suggest, no double entries etc, looks more like a file management, list of open files, than a history of visited sites. So I suggest to separate the functionality, between file management and history, therefore the two functions.

The toolbar buttons indeed needs to be more careful activation/deactivation. I will look later a little bit into this.

[pepdiz]

However, it is important to not blow up the widget with too many more or less specific features, it should just provide the basic functionality to browse a set of HTML or Markdown files.

Ok, so let's say basic functionality is history with traveling (back, forth, close, quick combo), local files (html and markdown) with local images and basic zoom, is it ok?

However it should offer methods and options to extend the functionality by the user/developer. That for instance is the browsecmd option thought for, you, as a developer, can keep track of all visited files and anchor links in the script given to that option. To simplify this even more, I now added as well two public methods getFiles and getHistory which can be used to retrieve this information directly. BTW: The functionality you suggest, no double entries etc, looks more like a file management, list of open files, than a history of visited sites. So I suggest to separate the functionality, between file management and history, therefore the two functions.

Ok but I don't fully understand the difference in terms of user experience between history and open files, I will explain on this in another issue

I undestand there's only one file rendered in the widget at a time, so you're reading and rendering each file as long as you move across history (except when dealing with fragmets of a file)