devhelp issueshttps://gitlab.gnome.org/GNOME/devhelp/-/issues2023-11-23T19:50:31Zhttps://gitlab.gnome.org/GNOME/devhelp/-/issues/71Open Link in New Window is broken2023-11-23T19:50:31ZMichael CatanzaroOpen Link in New Window is brokenRight click on any link and select Open Link in New Window. Nothing happens.
This context menu item has been broken for years. I just haven't bothered to report it until now. I'm using devhelp 43.0.Right click on any link and select Open Link in New Window. Nothing happens.
This context menu item has been broken for years. I just haven't bothered to report it until now. I'm using devhelp 43.0.https://gitlab.gnome.org/GNOME/devhelp/-/issues/70Devhelp doesn't have documentation by default2023-06-12T19:16:21ZRocketRideDevhelp doesn't have documentation by defaultThe problem is devhelp is not usable out of the box. I bet currently what most users do:
1. Install Devhelp
2. Open it and find out that there are no docs
3. Open software center and read description
4. Description didn't help. Search `g...The problem is devhelp is not usable out of the box. I bet currently what most users do:
1. Install Devhelp
2. Open it and find out that there are no docs
3. Open software center and read description
4. Description didn't help. Search `gtk4 docs devhelp` in internet
5. Find Ebassi's explanation in Discourse.
6. Install `org.gnome.Sdk.Docs`
My suggestion is to automatically install `org.gnome.Sdk.Docs` runtime or at least add a note about this runtime to description in software center.https://gitlab.gnome.org/GNOME/devhelp/-/issues/69Show local rustdoc manuals2023-04-25T11:47:55ZPhilip WithnallShow local rustdoc manualsIt would be useful to be able to view Rust documentation in Devhelp, alongside other development documentation.
That would probably mean finding manuals in `/usr/share/doc/rust/html` and using the `search-index*.js` file to provide sear...It would be useful to be able to view Rust documentation in Devhelp, alongside other development documentation.
That would probably mean finding manuals in `/usr/share/doc/rust/html` and using the `search-index*.js` file to provide search functionality and a basic symbol list.
This would be fine for the Rust manual itself (standard libraries), but I suspect it would break down a bit when looking at the docs for other cargo crates, since each project uses different versions of the crates they depend on. Devhelp might need to become aware of that and only show documentation from your current project’s cargo environment. (Or just not show documentation for non-standard/non-system-installed crates.)
If this idea doesn’t seem like a good fit for Devhelp, or you have a different plan for making Rust documentation available in a handy searchable UI that isn’t just Yet Another Browser Tab, then please go ahead and close this! In that case it would be good to have a definitive statement that Devhelp is not going to move in that direction.https://gitlab.gnome.org/GNOME/devhelp/-/issues/68Flatpak version doesn't recognize the locally installed books2023-11-23T19:49:20ZRichard SchwalkFlatpak version doesn't recognize the locally installed booksDevhelp flatpak version: 43.0
Doesn't show the installed books from $XDG_DATA_HOME/devhelp/books
The same version installed as rpm package on Fedora shows all the documentations.Devhelp flatpak version: 43.0
Doesn't show the installed books from $XDG_DATA_HOME/devhelp/books
The same version installed as rpm package on Fedora shows all the documentations.https://gitlab.gnome.org/GNOME/devhelp/-/issues/67Add a way to constrain search to specific manuals2022-12-02T04:22:55ZMohammed SadiqAdd a way to constrain search to specific manualsI often want to see search results only from certain version of a library (eg: GTK3/GDK3 when developing GTK3 apps, and GTK4/GSK/GDK4 when developing GTK4). Right now, I want open to see if it's GTK 3/4. It would be nice if there is a w...I often want to see search results only from certain version of a library (eg: GTK3/GDK3 when developing GTK3 apps, and GTK4/GSK/GDK4 when developing GTK4). Right now, I want open to see if it's GTK 3/4. It would be nice if there is a way to filter search to certain categories.https://gitlab.gnome.org/GNOME/devhelp/-/issues/66Auto convert links to local books2022-11-25T06:53:54ZMazhar HussainAuto convert links to local books# What happens
A lot of times when I'm reading a Devhelp book, I click on link and it opens up that link in my web browser instead of opening up a local Devhelp book.
For example, in the page for GtkApplication, there is a link for GApp...# What happens
A lot of times when I'm reading a Devhelp book, I click on link and it opens up that link in my web browser instead of opening up a local Devhelp book.
For example, in the page for GtkApplication, there is a link for GApplication and when I click on it, it opens it in my web browser even though the Devhelp book for Gio is installed on my system.
This is annoying.
# What I would like to happen
I would like for the web link to GApplication to be replaced with a local link to a page in the relevant Devhelp book.
## Details
IMHO, the root tag (book) could have a `online-url` attribute and when a link is clicked by the user and it starts with that url, it should be replaced with a link to a page in the book.
For example, the Devhelp book for Gio could have it's `<book>` tag like below
```xml
<book xmlns="http://www.devhelp.net/book" version="2"
name="Gio"
title="Gio-2.0 Reference Manual"
link="index.html"
author="GTK Development Team"
online-url="https://docs.gtk.org/gio"
language="c">
```
And when the book for Gio is loaded, the app could memorize that links starting with "https://docs.gtk.org/gio" belong to this book.
So, when I click on a link that points to "https://docs.gtk.org/gio/class.Application.html" from anywhere inside the app, it should open a page of the Gio book whose "link" attribute is "class.Application.html" instead (only if it exists, of course).
In other words, "https://docs.gtk.org/gio/class.Application.html" becomes "`Gio` > `class.Application.html`" because "https://docs.gtk.org/gio" = `Gio`.https://gitlab.gnome.org/GNOME/devhelp/-/issues/64devhelp 41.3 from flatpak doesn't scroll2022-09-12T18:15:18ZJonathan Blandforddevhelp 41.3 from flatpak doesn't scrollI'm running the latest devhelp from flathub (41.3), and it's not visually scrolling immediately when I scroll with middle mouse wheel or the keyboard. Instead, I have to click to get it to update the position visually. Scrolling with the...I'm running the latest devhelp from flathub (41.3), and it's not visually scrolling immediately when I scroll with middle mouse wheel or the keyboard. Instead, I have to click to get it to update the position visually. Scrolling with the scrollbar works as expected.
Here's a (somewhat lame) screencast exhibiting this broken behaviour. In this instance, I scroll down using the mouse wheel and nothing happens. When I click in the window at the end, it jumps down to the new location.https://gitlab.gnome.org/GNOME/devhelp/-/issues/60Empty page, whatever the entry2022-07-17T15:05:30ZgddEmpty page, whatever the entryOn `devhelp 41.2`, start page is empty and still empty whatever the page wanted.
![screenshot-20220428-095228](/uploads/7496160a1c61258d121cbd474e7a811a/screenshot-20220428-095228.png)
![screenshot-20220428-095236](/uploads/4ea6ccbcff3...On `devhelp 41.2`, start page is empty and still empty whatever the page wanted.
![screenshot-20220428-095228](/uploads/7496160a1c61258d121cbd474e7a811a/screenshot-20220428-095228.png)
![screenshot-20220428-095236](/uploads/4ea6ccbcff3df3e51b43b3e58fca59d4/screenshot-20220428-095236.png)
![screenshot-20220428-095242](/uploads/69182689a90e3e171ecbe8274abb490a/screenshot-20220428-095242.png)https://gitlab.gnome.org/GNOME/devhelp/-/issues/58Support dark mode preference2022-02-20T14:31:21ZMaximilianoSupport dark mode preferenceGNOME 42 will have a dark style preference, it would be good to support it.
* [ ] Follow the preference if applicable
* [ ] Adjust in-app dark style preferences, if there are any
* [ ] Ensure the app is usable and has decent contrast wi...GNOME 42 will have a dark style preference, it would be good to support it.
* [ ] Follow the preference if applicable
* [ ] Adjust in-app dark style preferences, if there are any
* [ ] Ensure the app is usable and has decent contrast with dark appearance
Read more about this at the [initiative](https://gitlab.gnome.org/GNOME/Initiatives/issues/32), @exalm, @BrainBlasted and @msandova will help with the implementation of it. Let us know if you have any questions & thoughts.
Testing with dark mode, it seems to be working fine expect for old GTK Doc generated sites, which is probably out of scope. It should just amount to adding libhandy =>1.5 as a dependency and opting into the preference.https://gitlab.gnome.org/GNOME/devhelp/-/issues/57Have a GNOME Search Provider2021-11-16T18:30:59ZKeith Baileykbailey4444@gmail.comHave a GNOME Search ProviderDevhelp having a search provider would make searching for API documentation faster.Devhelp having a search provider would make searching for API documentation faster.https://gitlab.gnome.org/GNOME/devhelp/-/issues/54Don't treat rc as a devel build2021-09-08T00:45:22ZJeremy BichaDon't treat rc as a devel buildWhen devhelp's version number contains "rc", [it sets the build profile](https://gitlab.gnome.org/GNOME/devhelp/-/blob/main/meson.build#L73-81) to devel, which changes the headerbar theming, changes the application ID, and changes the ap...When devhelp's version number contains "rc", [it sets the build profile](https://gitlab.gnome.org/GNOME/devhelp/-/blob/main/meson.build#L73-81) to devel, which changes the headerbar theming, changes the application ID, and changes the app logo.
I think this conflicts with the intent of the Release Candidate. For instance, it interferes with being able to take release quality screenshots.https://gitlab.gnome.org/GNOME/devhelp/-/issues/51Restructure Devhelp's UI2022-12-15T09:36:02ZEmmanuele BassiRestructure Devhelp's UIThe 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 up...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 a `GtkGrid`
- let's interpose a `GtkStack` with an empty state widget in one page and the `DhTab` 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`
- 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
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.GNOME 42https://gitlab.gnome.org/GNOME/devhelp/-/issues/50Implement an empty stage page2021-08-13T17:11:34ZEmmanuele BassiImplement an empty stage pageWhen opening Devhelp without a selected book, we should display a hint of what you're supposed to do next.
A simple empty state, with:
- the Devhelp icon, or an asset from the design team
- a helpful text, like: "Select a book from the...When opening Devhelp without a selected book, we should display a hint of what you're supposed to do next.
A simple empty state, with:
- the Devhelp icon, or an asset from the design team
- a helpful text, like: "Select a book from the side panel"
When using Devhelp as a flatpak application, we can also add a button that automatically installs the latest stable `org.gnome.Sdk.Docs` extension.GNOME 42https://gitlab.gnome.org/GNOME/devhelp/-/issues/49Remove GUI-related API from libdevhelp2023-08-29T21:51:51ZEmmanuele BassiRemove GUI-related API from libdevhelpThere are too many widgets in the API; they leak the details of how Devhelp is put together, and they become part of the API/ABI to the point that it gets progressively harder to change what really amounts to an implementation detail.
F...There are too many widgets in the API; they leak the details of how Devhelp is put together, and they become part of the API/ABI to the point that it gets progressively harder to change what really amounts to an implementation detail.
For instance: `DhTab` is a `GtkGrid`, instead of being a `GtkBin` with a `GtkGrid` inside it. To be fair, there's literally no reason why it should be a container to begin with, but `GtkBin` is probably the easiest widget we can make with GTK3.GNOME 42https://gitlab.gnome.org/GNOME/devhelp/-/issues/48Allow selecting the org.gnome.Sdk.Docs runtime extension2021-07-22T16:54:30ZEmmanuele BassiAllow selecting the org.gnome.Sdk.Docs runtime extensionWe currently load all documentation found in the Flatpak run time used by Devhelp, which works well enough for viewing the documentation of the current release of GNOME.
Ideally, though, we want to be able to list all the available run ...We currently load all documentation found in the Flatpak run time used by Devhelp, which works well enough for viewing the documentation of the current release of GNOME.
Ideally, though, we want to be able to list all the available run times with the `org.gnome.Sdk.Docs` extension installed; once selected, we need to instantiate the sandbox for the run time, and navigate in that sandbox.https://gitlab.gnome.org/GNOME/devhelp/-/issues/46Create gtk-doc links for devhelp2021-05-17T16:19:40ZAdministratorCreate gtk-doc links for devhelp## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#704462)](https://bugzilla.gnome.org/show_bug.cgi?id=704462)**
## Description
When using a system-wide devhelp, it would be nice if it picked up the documentation fro...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#704462)](https://bugzilla.gnome.org/show_bug.cgi?id=704462)**
## Description
When using a system-wide devhelp, it would be nice if it picked up the documentation from modules that have been jhbuilt. For example, compiling the latest glib and GTK+ from jhbuild should show the docs in the system-wide devhelp.
The code to make this work manually is a simple:
ln -s $jhbuild_prefix/share/gtk-doc ~/.local/share/
which jhbuild could do.
It would also be nice to mention this (when it works) in HowDoI/Jhbuild so that people use --enable-gtk-doc as a defaut configure flag (and can then easily test new docs).https://gitlab.gnome.org/GNOME/devhelp/-/issues/45Asynchronous I/O2021-05-17T15:50:17ZAdministratorAsynchronous I/O## Submitted by Sébastien Wilmet `@swilmet`
**[Link to original bug (#793850)](https://bugzilla.gnome.org/show_bug.cgi?id=793850)**
## Description
Asynchronous I/O.
Currently everything is synchronous. It would be nice to do async ...## Submitted by Sébastien Wilmet `@swilmet`
**[Link to original bug (#793850)](https://bugzilla.gnome.org/show_bug.cgi?id=793850)**
## Description
Asynchronous I/O.
Currently everything is synchronous. It would be nice to do async I/O.
For loading the index file, DhBook could implement the GAsyncInitable interface (part of GIO).https://gitlab.gnome.org/GNOME/devhelp/-/issues/37Add DBus interface for the most basic functions2021-05-17T15:49:36ZAdministratorAdd DBus interface for the most basic functions## Submitted by Thorsten Sick `@Thorsten-Sick`
**[Link to original bug (#614079)](https://bugzilla.gnome.org/show_bug.cgi?id=614079)**
## Description
At least opening a dehelp window and searching for strings should be possible with...## Submitted by Thorsten Sick `@Thorsten-Sick`
**[Link to original bug (#614079)](https://bugzilla.gnome.org/show_bug.cgi?id=614079)**
## Description
At least opening a dehelp window and searching for strings should be possible with DBus. Maybe add some more functionality.
This would allow more people to integrate devhelp into their tools.https://gitlab.gnome.org/GNOME/devhelp/-/issues/36Add session support, save/restore state2021-05-17T15:49:31ZAdministratorAdd session support, save/restore state## Submitted by Michael Ekstrand
**[Link to original bug (#405379)](https://bugzilla.gnome.org/show_bug.cgi?id=405379)**
## Description
Devhelp does not currently (as of 0.12) have support for sessions. It would make life with devh...## Submitted by Michael Ekstrand
**[Link to original bug (#405379)](https://bugzilla.gnome.org/show_bug.cgi?id=405379)**
## Description
Devhelp does not currently (as of 0.12) have support for sessions. It would make life with devhelp easier if it would save session state (open windows, open tabs, current documents and position within the document) as other GNOME apps do.
Other information:
Version: git masterhttps://gitlab.gnome.org/GNOME/devhelp/-/issues/35Command line option to open a devhelp book2021-05-17T15:49:23ZAdministratorCommand line option to open a devhelp book## Submitted by Richard Hult
**[Link to original bug (#351734)](https://bugzilla.gnome.org/show_bug.cgi?id=351734)**
## Description
Could be nice to be able to open a .devhelp2 directly (without having to deal with the paths devhelp...## Submitted by Richard Hult
**[Link to original bug (#351734)](https://bugzilla.gnome.org/show_bug.cgi?id=351734)**
## Description
Could be nice to be able to open a .devhelp2 directly (without having to deal with the paths devhelp knows, i.e. something like "devhelp foo.devhelp2".
Version: git master