Move document outline from hidden transient popover to a sidebar

[Vanadiae]

Since the wikipedia page's own document outline is hidden in Wike, the only place where the outline can be accessed is from the not very visible popover in the headerbar. Since it's implemented as a popover menu, it can't be shown in a tree-like manner, making it a bit more difficult to find a particular information from the (usually) quite general top-level headings. As such, I wonder if the document outline could be moved to a sidebar (on the left?) shown in a tree-like manner for easier access. That would make it nicer to use and more accessible there IMO :)

---

On a related note, I'd like to thank you for making this very nice app! :) I often read wikipedia pages and this app allows me to have a more native and specialised app for reading Wikipedia, while separating it from the main browser activities (the same as e.g. a wiktionnary or software documentation app provide). I don't know trademark laws, but I wonder if a permission is needed from the Wikimedia Foundation to use the "W" in the logo. The logo already seems to respect the Visual identity guidelines, but its use here isn't explicitely in the YES section of the Trademark Policy, so maybe "getting a regular license" is needed from there? I doubt they would object to its use, but it's likely a good idea to get that sorted out.

[hugolabe]

I contemplated at some point the option of putting a panel, but I really prefer to keep the main window as clean as possible, focused on the content of the article.

I think GTK's nested menus are a great option for displaying these tables of contents (which are sometimes very long). This option allows you to always have the menu available, unlike the table shown in Wikipedia pages, which is located in a fixed position and disappears from view as soon as you scroll through the article.

[vanillajonathan]

I agree with @Vanadiae, navigating through the nested menus is non-intuitive and difficult. It also makes it difficult to get a grasp of the article, to get an overview. You have to enter and exit each submenu to find out what is there.

@hugolabe You can still have a clean main window with a sidebar that can be hidden and have a toggle to show it, such as the F9 key which is used to show/hide the sidebar in Nautilus, gedit, Evince, Shotwell, etc.

[hugolabe]

I agree that this option would provide a more global view of the document, but I also like the simplicity of the current menu.

I will not rule it out in the future, but it is an important change in the UI of the app, and it is something that I have to study calmly. Maybe when migrating to GTK4 it's a good time to rethink it ...

[vanillajonathan]

I think it is a very good idea with a sidebar because it could be hidden and the UI could remain the same or pretty much the same.

Yes, I think it would be a good idea to wait for this til after the GTK4 migration since this involves UI so doing it later will be easier else you have to port that code too, and the widgets you might use might be difference since GTK4 has some new widgets for things such as tables, trees and lists.

[wyatt-turn]

Loving the application! Although I do also agree I think having a sidebar table of contents during a GTK4 migration would be great! I found while using it it was a little awkward for me to quickly jump between sections or see an overview.
I do get the need to keep the main view as simple as possible, although I don't think it would necessarily clutter it up either. I think the Gnome document viewer is a pretty good reference of what it could look and function like with its outline view on its navigation pop over.

[janxkoci]

The collapsible sidebar is a good idea. If you implement it in the future, do you plan to shrink-and-reflow the article text, or instead "slide" the sidebar outwards, changing window dimensions? I guess the first approach is more common in GNOME apps, I've seen the other mostly in apps from outside (playlist sidebar in the Xfce video player Parole comes to mind as an example).

My thinking is that text reflow can cause a user to loose position where they stopped reading. On the other hand, if somebody opens TOC sidebar, they probably intend to read a different part now, so the issue of text reflow could be moot. Unless there is another use for the sidebar then just to pick a different chapter to read, I guess. Like getting article overview...? 🤔 😅

[hugolabe]

The sidebar in Wike2 will have two modes of use.

By default, the panel overlays the article content and is hidden on action, so it doesn't affect the flow of the page.

For those who prefer to have it always visible, there is also the option to pin it.

wike2-sidebar.mp4

[janxkoci]

Whoa, that's even more awesome than I thought 😁

[AleuqabAli]

The sidebar in Wike2 will have two modes of use.

By default, the panel overlays the article content and is hidden on action, so it doesn't affect the flow of the page.

For those who prefer to have it always visible, there is also the option to pin it.

wike2-sidebar.mp4

is there any updates for the Libadwaita port?

[hugolabe]

is there any updates for the Libadwaita port?

No, since there is no stable version of Webkit for GTK4 yet. As far as I know, it is expected for GNOME 44.

[AleuqabAli]

GNOME 44 has been released and webkitgtk-6.0 is now stable.