Skip to content
Commits on Source (100)
# SPDX-FileCopyrightText: 2021 Emmanuele Bassi
#
# SPDX-License-Identifier: CC0-1.0
root = true
[*]
indent_style = space
indent_size = 8
insert_final_newline = true
trim_trailing_whitespace = true
end_of_line = lf
charset = utf-8
[*.json]
indent_size = 2
[*.md]
max_line_length = 79
[meson.build]
indent_size = 4
Johan Dahlin <johan@gnome.org>
Mikael Hallendal <micke@imendio.com>
Richard Hult <richard@imendio.com>
Ross Burton <ross@burtonini.com>
Aleksander Morgado <aleksander@lanedo.com>
Frédéric Péters
Sébastien Wilmet
# Contribution guidelines
Thank you for considering contributing to the Devhelp project!
These guidelines are meant for new contributors, regardless of their level
of proficiency; following them allows the maintainers of the Devhelp project
to more effectively evaluate your contribution, and provide prompt feedback
to you. Additionally, by following these guidelines you clearly communicate
that you respect the time and effort that the people developing Devhelp put
into managing the project.
Devhelp would not exist without contributions from the free and open source
software community. There are many things that we value:
- bug reporting and fixing
- documentation and examples
- tests
- new features
Please, do not use the issue tracker for support questions. If you have
questions on how to use Devhelp effectively, you can use:
- the [devhelp tag on the GNOME Discourse instance](https://discourse.gnome.org/tag/devhelp)
The issue tracker is meant to be used for actionable issues only.
## How to report bugs
### Security issues
If you wish to report a security-related issue, please follow the
instructions available on the [GNOME security
website](https://security.gnome.org).
### Bug reports
If you're reporting a bug make sure to list:
0. which version of Devhelp are you using?
0. which operating system are you using?
0. the necessary steps to reproduce the issue
0. the expected outcome
0. a description of the behavior; screenshots are also welcome
If the issue includes a crash, you should also include:
0. the eventual warnings printed on the terminal
0. a backtrace, obtained with tools such as GDB or LLDB
It is fine to include screenshots of screen recordings to demonstrate
an issue that is best to understand visually, but please don't just
dump screen recordings without further details into issues. It is
essential that the problem is described in enough detail to reproduce
it without watching a video.
For small issues, such as:
- spelling/grammar fixes in the documentation
- typo correction
- comment clean ups
- changes to metadata files (CI, `.gitignore`)
- build system changes
- source tree clean ups and reorganizations
You should directly open a merge request instead of filing a new issue.
### Features and enhancements
Feature discussion can be open ended and require high bandwidth channels; if
you are proposing a new feature on the issue tracker, make sure to make
an actionable proposal, and list:
0. what you're trying to achieve
0. prior art, in other toolkits or applications
0. design and theming changes
If you're proposing the integration of new features it helps to have
multiple applications using shared or similar code, especially if they have
iterated over it various times.
Each feature should also come fully documented, and with tests.
## Your first contribution
### Prerequisites
If you want to contribute to the Devhelp project, you will need to have the
development tools appropriate for your operating system, including:
- Python 3.x
- Meson
- Ninja
- Gettext (19.7 or newer)
- a [C99 compatible compiler](https://wiki.gnome.org/Projects/GLib/CompilerRequirements)
Up-to-date instructions about developing GNOME applications and libraries
can be found on [the GNOME Developer Center](https://developer.gnome.org).
The Devhelp project uses GitLab for code hosting and for tracking issues. More
information about using GitLab can be found [on the GNOME wiki](https://wiki.gnome.org/GitLab).
### Dependencies
Devhelp depends on various libraries that are part of the GNOME application
development platform:
- GTK
- WebKitGTK
Additionally, you will need the following settings module installed:
- gsettings-desktop-schemas
### Getting started
You should start by forking the Devhelp repository from the GitLab web UI, and
cloning from your fork:
```sh
$ git clone https://gitlab.gnome.org/yourusername/devhelp.git
```
We recommend using [GNOME Builder](https://wiki.gnome.org/Apps/Builder),
which will automatically use the Flatpak manifest and build Devhelp in a
containerized environment.
To compile the Git version of Devhelp on your system, you will need to
configure your build using Meson:
```sh
$ meson setup _builddir .
$ meson compile -C _builddir
```
Typically, you should work on your own branch:
```sh
$ git switch -C your-branch
```
Once you've finished working on the bug fix or feature, push the branch
to the Git repository and open a new merge request, to let the Devhelp
maintainers review your contribution.
### Code reviews
Each contribution is reviewed by the maintainers of the Devhelp project.
Just remember that the maintainers are volunteers just like you, so they
might take some time to review your contributions. Please, be patient.
### Commit messages
The expected format for git commit messages is as follows:
```plain
Short explanation of the commit
Longer explanation explaining exactly what's changed, whether any
external or private interfaces changed, what bugs were fixed (with bug
tracker reference if applicable) and so forth. Be concise but not too
brief.
Closes #1234
```
- Always add a brief description of the commit to the _first_ line of
the commit and terminate by two newlines (it will work without the
second newline, but that is not nice for the interfaces).
- First line (the brief description) must only be one sentence and
should start with a capital letter unless it starts with a lowercase
symbol or identifier. Don't use a trailing period either. Don't exceed
72 characters.
- The main description (the body) is normal prose and should use normal
punctuation and capital letters where appropriate. Consider the commit
message as an email sent to the developers (or yourself, six months
down the line) detailing **why** you changed something. There's no need
to specify the **how**: the changes can be inlined.
- When committing code on behalf of others use the `--author` option, e.g.
`git commit -a --author "Awesome Coder <awesome@coder.org>"` and `--signoff`.
- If your commit is addressing an issue, use the
[GitLab syntax](https://docs.gitlab.com/ce/user/project/issues/automatic_issue_closing.html)
to automatically close the issue when merging the commit with the upstream
repository:
```plain
Closes #1234
Fixes #1234
Closes: https://gitlab.gnome.org/GNOME/devhelp/issues/1234
```
- If you have a merge request with multiple commits and none of them
completely fixes an issue, you should add a reference to the issue in
the commit message, e.g. `Bug: #1234`, and use the automatic issue
closing syntax in the description of the merge request.
How to contribute to Devhelp
============================
Devhelp is hosted on the GNOME GitLab instance, you can fork the repository and
then do a merge request:
https://gitlab.gnome.org/GNOME/devhelp
Read the following wiki page to know the conventions for the commit messages:
https://wiki.gnome.org/Git/CommitMessages
Devhelp philosophy
------------------
The tool is generic and can be used by other development communities, as long
as the API documentation is available in HTML and a *.devhelp2 index file is
generated. It's important to keep the door open to other development
communities, to increase diversity, and maybe bring more funding to develop
developer tools.
If you want to make the Devhelp application GNOME-specific, for example to have
a start page specific to GNOME libraries, or to download API references from
gnome.org, read the next paragraph.
Sébastien Wilmet has done a lot of refactorings to the code, to follow the
“as a library” philosophy, like for the LLVM project [1]. Almost all the code
is written as a flexible library. With a DAG (Directed Acyclic Graph) of
classes for the containment hierarchy. With the goal to create a software
product line [2] for Devhelp: keep the Devhelp application generic, and create
a new application specific to GNOME, with both applications having a really
small codebase (the GNOME-specific features would be written as a configurable
library as well). For more information see also [3].
[1] “a corpus of functionality built as a set of libraries that can be sliced
and remixed in different ways per the needs of different use-cases”
(Chris Lattner, original co-author of LLVM),
http://lists.llvm.org/pipermail/llvm-dev/2019-June/133274.html
[2] https://www.amazon.com/Feature-Oriented-Software-Product-Lines-Implementation/dp/3642375200/
[3] https://swilmet.be/blog/2019/08/18/10-years-later/
Source code locations
---------------------
The library (libdevhelp) is in the `devhelp/` directory so that an `#include`
like the following works when compiling the code:\
`#include <devhelp/[…].h>`
The application is in `src/`. (Not `src-app/` or something like it). Rationale:
it is planned to split the Git repository in two in the future, to separate the
library from the application. When there will only be the application in a git
repository, `src/` is the usual name. And historically all the source code (lib
and app) was in `src/`.
C code conventions
------------------
Devhelp follows the Linux kernel coding style, with some exceptions:
- Indentation: 8 spaces, not tabs.
- One space before *each* opening parenthesis.
- Multi-line comments must be like this:
/* First line.
* Second line.
*/
GObject classes must not be created with a G_DECLARE macro, it causes more
problems than it solves:
https://blogs.gnome.org/swilmet/2015/10/10/changing-quickly-between-a-final-and-derivable-gobject-class/
g_auto macros are not used, because:
1. It makes debugging more difficult in case of a memory handling problem.
2. It breaks the uniformity of memory handling in C. Uniformity is an important
principle for programming language design, as explained in the book
“The Psychology of Computer Programming”:
https://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp/0932633420/
3. The developer needs to be very careful when using g_auto in certain
circumstances:
https://blog.fishsoup.net/2015/11/05/attributecleanup-mixed-declarations-and-code-and-goto/
See also:
https://developer.gnome.org/programming-guidelines/unstable/
Flatpak
-------
The Devhelp maintainers maintain both the nightly and the stable versions of
the Devhelp Flatpak.
The nightly version is in flatpak/ and the gnome-apps-nightly module:
https://gitlab.gnome.org/GNOME/gnome-apps-nightly
The stable version is on Flathub:
https://github.com/flathub/org.gnome.Devhelp
News in 41.rc, 2021-09-04
-------------------------
* Translation updates
News in 41.beta, 2021-08-14
---------------------------
* Translation updates
* Fix build in sandboxed environments with no network
* Update list of translatable files [#47]
* Switch to gi-docgen to build the libdevhelp API reference
* Move the "Show side panel" action from the menu to the header bar [!36]
* Fix donation link in the appdata information [!39]
* Build against WebKitGTK 4.1 [!38]
* Build against GLib 2.70 [!40]
News in 41.alpha, 2021-07-09
----------------------------
* Translation updates
* Drop the dependency on AMTK
* Build fixes with newer versions of various dependencies
* Follow the HIG best practices for the main menu button
* Drop the old "simple" menu fallback
* Display find shortcuts in the Keyboard Shortcuts dialog [#27]
* Search for Devhelp files under `$datadir/doc` [#29]
* Set the User Agent for client-side detection [#28]
* Add a custom CSS to allow documentation generators to control the
rendering under Devhelp
News in 40.0, 2021-04-12
------------------------
* Translation updates.
......
Devhelp
=======
The Devhelp web page:
Description
-----------
Devhelp is a developer tool for browsing and searching API documentation.
It provides an easy way to navigate through libraries and to search by
function, struct, or macro.
https://wiki.gnome.org/Apps/Devhelp
The documentation must be installed locally, so an internet connection is
not needed to use Devhelp.
Devhelp works natively with the documentation generators used by the GNOME
project libraries. Other development platforms can be supported as well, as
long as the API documentation is available in HTML and a `*.devhelp2` index
file is generated.
Devhelp integrates with other applications such as Glade, Builder or
Anjuta, and plugins are available for different text editors (gedit, Vim,
Emacs, Geany, …).
Installation of the Devhelp Flatpak
-----------------------------------
......@@ -13,7 +28,7 @@ Installation of the Devhelp Flatpak
How to contribute
-----------------
See the [HACKING](HACKING) file.
See the [contribution guide](CONTRIBUTING.md).
Dependencies
------------
......@@ -21,28 +36,8 @@ Dependencies
- GLib
- GTK
- WebKitGTK
- [Amtk](https://wiki.gnome.org/Projects/Amtk)
- gsettings-desktop-schemas
Description
-----------
Devhelp is a developer tool for browsing and searching API documentation.
It provides an easy way to navigate through libraries and to search by
function, struct, or macro.
The documentation must be installed locally, so an internet connection is
not needed to use Devhelp.
Devhelp works natively with GTK-Doc, so the GTK and GNOME libraries are
well supported. But other development platforms can be supported as well,
as long as the API documentation is available in HTML and a `*.devhelp2`
index file is generated.
Devhelp integrates with other applications such as Glade, Builder or
Anjuta, and plugins are available for different text editors (gedit, Vim,
Emacs, Geany, …).
Integration with other developer tools
--------------------------------------
......@@ -55,7 +50,7 @@ Devhelp also provides a shared library, to integrate the GTK widgets inside an
IDE. It is used for example by Builder and Anjuta.
For the `--search` command line option, see the class description of
DhKeywordModel, the search string supports additional features useful for IDEs
`DhKeywordModel`, the search string supports additional features useful for IDEs
or other developer tools.
Other documentation
......@@ -67,3 +62,20 @@ Other documentation
- There is an API reference manual for the libdevhelp that can be built with
GTK-Doc, see the `gtk_doc` build option.
Default development branch
--------------------------
The default development branch of Devhelp has been renamed to `main`. If you
have just cloned the Devhelp repository, you don't need to change anything.
If you have an older local checkout, you can use these commands to switch
from the old default branch name to the new one:
```
git switch master
git branch -m master main
git fetch
git branch --unset-upstream
git branch -u origin/main
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
```
Possible things to do in Devhelp
================================
Normally all the codebase is in a good state, except DhAssistant because I
Normally all the codebase is in a good state, except `DhAssistant` because I
don't use it (and I think it's sometimes broken).
Some stuff that can be done:
Improve DhBookList API
----------------------
Improve `DhBookList` API
------------------------
Make it easier to create a custom DhBookList. Maybe expose publicly
DhBookListSimple and be able to subclass it.
Make it easier to create a custom `DhBookList`. Maybe expose publicly
`DhBookListSimple` and be able to subclass it.
Have man-pages for the lib C
----------------------------
https://bugzilla.gnome.org/show_bug.cgi?id=616509#c6
See [issue 38](https://gitlab.gnome.org/GNOME/devhelp/-/issues/38).
Create a software product line
------------------------------
Improve `DhSettings`
--------------------
By moving almost all the code to the libdevhelp (so the software product line
is implemented by developing a library, using classic OOP design patterns).
Same idea as Tepl, but applied to a smaller codebase. See:
https://developer.gnome.org/tepl/unstable/intro.html
https://www.amazon.com/Feature-Oriented-Software-Product-Lines-Implementation/dp/3642375200/
In Devhelp it's almost done. What remains is DhApplicationWindow, DhApplication
(see how it is done in Tepl) and a toolkit to build a preferences dialog (my
plan was to at least factor out a DhBookChooser widget from DhPreferences).
Then with the software product line, different API browser products can be
created: a generic one (same as current Devhelp), one specific for GNOME, etc.
See also the roadmap on the wiki.
Improve DhSettings
------------------
See the comment in dh-settings.c.
See the comment in [`dh-settings.c`](./devhelp/dh-settings.c).
Rename some classes
-------------------
......@@ -50,6 +32,6 @@ or it should be done for the next major version of the libdevhelp, with the
different major versions being parallel-installable (which means moving the
libdevhelp to its own git repo).
- DhSidebar -> DhSidePanel. A "bar" in GNOME is more for horizontal things,
like GtkInfoBar.
- DhKeywordModel -> DhSearchModel ?
- `DhSidebar` -> `DhSidePanel`. A "bar" in GNOME is more for horizontal things,
like `GtkInfoBar`.
- `DhKeywordModel` -> `DhSearchModel` ?
TODO Devhelp attic
==================
Triage the files, remove what is no longer needed, and better document what is
still useful (if it's still useful it can be moved to another directory).
For describing the index file format, a *.rng file would be better. The
devhelp-1.dtd seems to describe the index file format version 1, which is
deprecated. What are the other *.dtd files?
<?xml version ="1.0" ?>
<!ELEMENT book (chapters,functions?)>
<!ATTLIST book title CDATA #REQUIRED
name CDATA #REQUIRED
base CDATA #IMPLIED
version CDATA #IMPLIED
link CDATA #REQUIRED
author CDATA #IMPLIED>
<!ELEMENT chapters (sub*,chapter*)>
<!ELEMENT chapter (sub*,chapter*)>
<!ATTLIST chapter name CDATA #REQUIRED
link CDATA #REQUIRED>
<!ELEMENT sub (sub*,chapter*)>
<!ATTLIST sub name CDATA #REQUIRED
link CDATA #REQUIRED>
<!ELEMENT functions (function+)>
<!ELEMENT function EMPTY>
<!ATTLIST function name CDATA #REQUIRED
link CDATA #REQUIRED>
<?xml version ="1.0" ?>
<!ELEMENT contents (section+)>
<!ELEMENT section (section*)>
<!ATTLIST section title CDATA #REQUIRED
url CDATA #REQUIRED>
<?xml version ="1.0" ?>
<!ELEMENT keywords (keyword+)>
<!ELEMENT keyword EMPTY>
<!ATTLIST keyword name CDATA #REQUIRED
url CDATA #REQUIRED>
<?xml version ="1.0" ?>
<!ELEMENT book>
<!ATTLIST book format-version CDATA #REQUIRED
title CDATA #REQUIRED
author CDATA #IMPLIED
main-section CDATA #REQUIRED
base-uri CDATA #IMPLIED>
<?xml version ="1.0" ?>
<!ELEMENT book (contents,keywords?)>
<!ATTLIST book format-version CDATA #REQUIRED
title CDATA #REQUIRED
author CDATA #IMPLIED
index-file CDATA #REQUIRED
base-url CDATA #IMPLIED>
<!ELEMENT contents (section+)>
<!ELEMENT section (section*)>
<!ATTLIST section title CDATA #REQUIRED
link CDATA #REQUIRED>
<!ELEMENT keywords (keyword+)>
<!ELEMENT keyword EMPTY>
<!ATTLIST keyword name CDATA #REQUIRED
link CDATA #REQUIRED>
#!/usr/bin/env python
import formatter
import htmllib
import sgmllib
import string
import sys
import os.path
import os
SKIP_DATA = [ "Next Page", "Previous Page", "Home", "Next", "Up", "<", ">"]
class HTMLParser (htmllib.HTMLParser):
is_a = 0
a = []
link = ""
def anchor_bgn (self, href, name, type):
self.is_a = 1
self.link = href
def anchor_end (self):
self.is_a = 0
def handle_data (self, data):
data = string.strip (data)
if data in SKIP_DATA:
return
if not '#' in self.link:
return
if self.link[:2] == "..":
return
if self.is_a and self.link:
self.a.append ((data, self.link))
def parse_file (filename, bookname):
fd = open (filename)
try:
p = HTMLParser (formatter.NullFormatter())
p.feed (fd.read())
p.close()
except KeyboardInterrupt:
raise SystemExit
return p.a
dirname = os.path.abspath (sys.argv[1])
bookname = os.path.basename (os.path.abspath (sys.argv[1]))
files = os.listdir (dirname)
files.sort()
funcs = []
for file in files:
if file[-5:] != ".html":
continue
print "parsing", file
links = parse_file (dirname + "/" + file, bookname)
for link in links:
if not link in funcs:
funcs.append (link)
print "Sorting function list"
funcs.sort()
filename = "%s/%s.index" % (dirname, bookname)
print "Writing index to", filename
fd = open (filename, "w")
fd.write ("<functions>\n")
for name, link in funcs:
if ' ' in name or '\n' in name:
continue
fd.write (' <function name="%s" link="%s"/>\n' % (name, link))
fd.write ("</functions>\n</book>\n")
fd.close()
#!/usr/bin/env python
import os.path
import sgmllib
import string
import sys
def does_dict_have_keys (dict, keys):
for key in keys:
if not dict.has_key (key):
return 0
if len(dict) != len(keys):
return 0
return 1
def walk (dict, level=0, parent=None):
if dict.has_key ('order'):
list = dict['order']
else:
list = dict.keys()
for key in list:
if key in ['name', 'order', 'link']:
continue
if dict[key].has_key ('link') and \
does_dict_have_keys (dict[key], ['link']):
link = dict[key]['link']
else:
link = ""
if level:
print '*' * level, key, '-', link
else:
print key, '-', link
walk (dict[key], level + 1, dict)
class BookParser (sgmllib.SGMLParser):
def __init__ (self):
sgmllib.SGMLParser.__init__ (self)
self.a = self.parents = []
self.dict = {}
self.last = self.link = ""
self.is_a = self.level = 0
self.first = 1
def unknown_starttag (self, tag, attrs):
if tag == 'a':
self.is_a = 1
for attr in attrs:
if attr[0] == "href":
self.link = attr[1]
break
if tag in ['dd', 'ul']:
self.parents.append (self.last)
self.level = self.level + 1
def unknown_endtag (self, tag):
if tag == 'a':
self.is_a = 0
if tag in ['dd', 'ul']:
self.level = self.level - 1
self.parents.pop()
def handle_data (self, data):
data = string.strip (data)
if not data or data in [ ">", "<" ]:
return
if self.first:
self.dict['name'] = data
self.first = 0
return
if data == self.dict['name'] or data in [ "Next Page", "Previous Page", "Home", "Next"]:
return
if len (self.parents) == 0:
dict = self.dict
elif len (self.parents) == 1:
dict = self.dict[self.parents[0]]
elif len (self.parents) == 2:
dict = self.dict[self.parents[0]][self.parents[1]]
elif len (self.parents) == 3:
dict = self.dict[self.parents[0]][self.parents[1]][self.parents[2]]
else:
dict = None
if self.is_a:
if dict == None:
return
if not dict.has_key (data):
dict[data] = {}
if not dict.has_key ('order'):
dict['order'] = []
dict['order'].append (data)
dict[data]['link'] = self.link
self.last = data
def parse_book (url):
if os.path.exists (url + "/index.html"):
filename = url + "/index.html"
elif os.path.exists (url + "/book1.html"):
filename = url + "/book1.html"
elif os.path.exists (url):
filename = url
else:
print "Error; Can't find an index :("
raise SystemExit
fd = open (filename)
p = BookParser()
p.feed (fd.read())
p.close()
return p.dict
filename = sys.argv[1]
dict = parse_book (sys.argv[1])
print '<?xml version="1.0"?>'
print '<book title="%s"\nname=""\nbase=""\nlink="%s">' % (dict['name'], os.path.basename (sys.argv[1]))
print '<chapters>'
for chap in dict['order']:
print ' <sub name="%s" link="%s">' % (chap, dict[chap]['link'])
if dict[chap].has_key ('order'):
for sub in dict[chap]['order']:
if not does_dict_have_keys (dict[chap][sub], ['link']):
print ' <sub name="%s" link="%s">' % (sub, dict[chap][sub]['link'])
for sub2 in dict[chap][sub]['order']:
print ' <sub name="%s" link="%s"/>' % (sub2, dict[chap][sub][sub2]['link'])
print ' </sub>'
else:
print ' <sub name="%s" link="%s"/>' % (sub, dict[chap][sub]['link'])
print ' </sub>'
print
print '</chapters>'
print
print '</book>'
#!/usr/bin/env python
import os
import os.path
import string
# Generates a *.devhelp index file (old format) for man pages.
# Just the index file, this script doesn't generate HTML pages for each man
# page.
# Add $GNOME_PATH/man too
#MAN_PATH = ["/usr/man", "/usr/share/man", "/usr/local/man"]
MAN_PATH = ["/usr/share/man"]
MAN_SUBS = ["man1", "man2", "man3", "man4", "man5",
"man6", "man7", "man8", "man9"]
MAN_NAME = { "man1" : "Applications",
"man2" : "System Calls",
"man3" : "Library Functions",
"man4" : "Devices",
"man5" : "Configuration Files",
"man6" : "Games",
"man7" : "Conventions",
"man8" : "System Administration",
"man9" : "Kernel Routines"}
# 1. Get a list of all mandirs
chapters = []
for mandir in MAN_PATH:
dir_list = os.listdir (mandir)
for dir in dir_list:
if os.path.isdir (mandir + "/" + dir) and dir in MAN_SUBS:
chapters.append (mandir + "/" + dir)
# 2. Get a list of all manpages
man_pages = {}
funcs = []
for mandir in chapters:
list = os.listdir (mandir)
for file in list:
# Extract the name of the man page
name, section = string.split (file, ".", 1)
if section[-3:] == ".gz":
section = section[:-3]
man = os.path.basename (mandir)
filename = mandir + "/" + file
# Check out section 2* and 3*, but not 3pm
if section in ['2', '3'] and section[-2:] != "pm":
# Remove perl funtions
if string.find (name, "::") == -1:
funcs.append ((name, filename))
# Does the the dict have the key?
if not man_pages.has_key (man):
man_pages[man] = []
if name == "." or not name:
continue
man_pages[man].append ((name, filename))
# 3. Print out xml
print '<?xml version="1.0"?>'
print '<book title="Man pages">'
print
# 3.1 Print chapters
# Chapters
chapters.sort()
written = []
print '<chapters>'
for chap in chapters:
name = os.path.basename (chap)
if not man_pages.has_key (name):
continue
if name in written:
continue
written.append (name)
print ' <chapter name="%s">' % MAN_NAME[name]
list = man_pages[name]
list.sort()
for name, page in list:
print ' <sub name="%s" link="%s"/>' % (name, page)
print ' </chapter>'
print
print '</chapters>'
print
# 3.2 print functions
# Functions
funcs.sort()
print '<functions>'
for name, file in funcs:
print ' <function name="%s" link="%s"/>' % (name, file)
print '</functions>'
print
print '</book>'
Flatpak for Devhelp
===================
- `org.gnome.Devhelp.json`: the Flatpak manifest for Devhelp
- `org.gnome.Devhelp.Devel.json`: The Flatpak manifest for Devhelp's
development profile
- `run-flatpak.sh`: a utility script for building, running, and uninstalling
the Devhelp Flatpak
If you want to build a Flatpak version of Devhelp:
1. make sure to have `flatpak` and `flatpak-builder` installed
2. `./run-flatpak build --app-id=org.gnome.Devhelp` to build and install
3. `./run-flatpak run --app-id=org.gnome.Devhelp` to run
4. `./run-flatpak clean --app-id=org.gnome.Devhelp` to uninstall
{
"app-id" : "org.gnome.Devhelp.Devel",
"runtime" : "org.gnome.Sdk",
"runtime-version" : "master",
"sdk" : "org.gnome.Sdk",
"command" : "devhelp",
"tags" : [
"nightly"
],
"desktop-file-name-prefix" : "(Development) ",
"finish-args" : [
"--share=ipc",
"--socket=x11",
"--socket=wayland",
"--device=dri",
"--filesystem=host:ro"
],
"cleanup" : [
"/include",
"/lib/pkgconfig",
"/share/pkgconfig",
"share/aclocal",
"man",
"share/man",
"*.la",
"*.a"
],
"modules" : [
{
"name" : "devhelp",
"buildsystem" : "meson",
"config-opts" : [
"-Dflatpak_build=true",
"-Dprofile=devel",
"-Dgtk_doc=false"
],
"run-tests" : true,
"sources" : [
{
"type" : "git",
"url" : "https://gitlab.gnome.org/GNOME/devhelp.git",
"branch" : "main"
}
]
}
]
}
{
"app-id" : "org.gnome.Devhelp",
"runtime" : "org.gnome.Sdk",
"runtime-version" : "master",
"sdk" : "org.gnome.Sdk",
"command" : "devhelp",
"tags" : [
"nightly"
],
"desktop-file-name-prefix" : "(Nightly) ",
"finish-args" : [
"--share=ipc",
"--socket=x11",
"--socket=wayland",
"--device=dri",
"--filesystem=host:ro"
],
"cleanup" : [
"/include",
"/lib/pkgconfig",
"/share/pkgconfig",
"share/aclocal",
"man",
"share/man",
"*.la",
"*.a"
],
"modules" : [
{
"name" : "devhelp",
"buildsystem" : "meson",
"config-opts" : [
"-Dflatpak_build=true",
"-Dprofile=stable",
"-Dgtk_doc=false"
],
"run-tests" : true,
"sources" : [
{
"type" : "git",
"url" : "https://gitlab.gnome.org/GNOME/devhelp.git",
"branch" : "main"
}
]
}
]
}