Restructure Devhelp's UI
The main obstacle in modernising the Devhelp UI—especially with an eye towards porting to GTK4—is that a bunch of UI components reside in libdevhelp for no good reason. The UI components encode the very structure that Devhelp is built upon, which makes changing anything a fractal of pain. For instance:
- we want to add an empty state to Devhelp
- start by adding a stack to the main window, with an empty state widget in one page, and the main view in the other
- the main view is really a
DhNotebook
, and we want an empty state for every page of the notebook - let's add a stack to each
DhTab
- except that the
DhTab
is aGtkGrid
- let's interpose a
GtkStack
with an empty state widget in one page and theDhTab
in the other - we have a bunch of state trackers that exist half in libdevhelp, and have in Devhelp, and all of them have to be made aware of this new structure
Another example:
- let's change the side panel to use libhandy
- the side panel is deeply tied to the structure of the window
- the side panel has a bunch of state trackers for
DhNotebook
While it's entirely possibly to break libdevhelp's API, it's probably safer to prototype the next iteration of Devhelp's UI and architecture in a way that keeps the existing out of tree users of libdevhelp—mainly Builder and Anjuta—running.
Strawman
Let us assume that libdevhelp cannot be changed.
We start with rebuilding the application's UI from the ground up. All the widgetry is part of the application.
We add new API to libdevhelp to deal with:
- book collections
- system collection: enumerates books in
$XDG_DATA_DIRS
- user collection: enumerates books in
$XDG_DATA_HOME
- custom collection: enumerates books in a given set of search paths
- sandbox collections: enumerates books under
/run/host/$XDG_DATA_DIRS
- system collection: enumerates books in
- book
- metadata:
- title
- main page
- author
- language
- structure: a tree of chapters and sub-chapters
- content: the list of HTML files of a book
- keywords: mapping from (type, name) to link
- metadata:
Each book collection is a GListModel
of books.
Search is performed inside a book by creating a search model, which gets updated by the search implementation.
The new libdevhelp API does not contain any UI component, only the data structures that can be used to enumerate, display, and search the books available to the user. All API is asynchronous by default.