[gimp-web-devel/pat/bootstrap] content: fix a bit the FAQ.



commit 6bfae59a56a51ba1d3c8ff1728235fc72e892414
Author: Jehan <jehan girinstud io>
Date:   Tue Sep 6 14:56:05 2022 +0200

    content: fix a bit the FAQ.
    
    We still have documents a bit too much everywhere. Eventually this
    should be factorized a bit to avoid so much duplication of information.
    For the time being, I just do simple cleanups.

 content/faq.md | 56 +++++++++++++++++++++++++++++---------------------------
 1 file changed, 29 insertions(+), 27 deletions(-)
---
diff --git a/content/faq.md b/content/faq.md
index 61a5eaa..a9be07b 100644
--- a/content/faq.md
+++ b/content/faq.md
@@ -15,19 +15,18 @@ regarding development of the GIMP.
 #### Who coordinates GIMP development?
 
 GIMP development is coordinated by Wilber the GIMP along
-with a loosely knit team of GIMP developers.  The
-developers can be reached through mailing list, IRC (see the
+with a loosely knit team of GIMP developers. The developers can be
+reached through mailing list, IRC (see the
 [Discuss](https://www.gimp.org/discuss.html) page) and the [bug tracking
 system](https://gitlab.gnome.org/GNOME/gimp/).
 
 #### How can I become a GIMP developer?
 
 If you are a developer who wants to start contributing
-code to the GIMP, the best way to get to know its
-structure is by fixing bugs reported in Gitlab.  Pick a
-bug, perhaps ask the advice of another developer as to
-whether he/she thinks it will be an easy bug or not, and
-then fix it.  Sounds easy, doesn't it?
+code to GIMP, the best way to get to know its structure is by fixing
+bugs reported in Gitlab. Pick a bug, perhaps ask the advice of another
+developer as to whether he/she thinks it will be an easy bug or not, and
+then fix it. Sounds easy, doesn't it?
 
 The [Core Development](/core_developers/) section is where you want to
 start.
@@ -41,11 +40,11 @@ list](https://www.gimp.org/discuss.html#mailing-lists),
 tracking system](https://gitlab.gnome.org/GNOME/gimp/).
 
 The GIMP has its own IRC channel on GIMPNet where most of
-the active developers hang out.  Join us in `#gimp` on
+the active developers hang out. Join us in `#gimp` on
 [irc.gimp.org](irc:://irc.gimp.org:6667/#gimp).
 
-Every once in a while the GIMP developers get together for
-a few days to throw a GIMP Developers Conference (historically referred
+Every once in a while, GIMP developers get together for a few days to
+throw a GIMP Developers Conference (historically referred
 to as `GIMPCon`), or during Libre Graphics Meeting. These days, a
 hacking event called "*Wilber Week*" also sometimes happen.
 
@@ -53,44 +52,47 @@ See the [Conferences](/conferences/) section.
 
 #### Where can I find documentation for the GIMP API?
 
-You can pass `--enable-gtk-doc` to the gimp `configure` script.  This
-requires having [gtk-doc](https://gitlab.gnome.org/GNOME/gtk-doc)
-installed. After running `make` you can find the GIMP API reference in
-the `devel-docs` directory.
+You can pass `-Dgi-docgen=enabled` to `meson`.
+
+After running `ninja` you can find the GIMP API reference in the
+`devel-docs` directory.
 
 Pre-generated API documentation is included in the
 official GIMP tarballs.
 
-The API reference will normally be installed in
-`PREFIX/share/gtk-doc/html`.  An on
-line version of the GIMP API reference can be found
+The API reference will normally be installed in `$PREFIX/share/doc/`.
+An online version of the GIMP API reference can be found
 [here](api/2.0/).
 
+*Note: these were the instructions for the `master` branch of GIMP, future
+GIMP 3.0. For 2.10 instructions: pass `--enable-gtk-doc` to the
+`configure` script and find installed docs in `$PREFIX/share/gtk-doc/html`.*
+
 #### How do I make a stack trace?
 
 A stack trace is a list of function calls that leads to
-some point in the program. Debugging tools like <ulink
-url="http://www.gnu.org/software/gdb/gdb.html";>gdb</ulink>
+some point in the program. Debugging tools like <a
+href="http://www.gnu.org/software/gdb/gdb.html";>gdb</a>
 can get stack traces from crashed applications so that
 developers can figure out what went wrong. By including a
 stack trace with your bug report, it will be much easier
 for the developers to fix the reported problem.
 
 Information on how to make a stack trace can be found in
-the document <ulink
-url="http://live.gnome.org/GettingTraces";>Capturing
-Stack Traces</ulink>.
+the document <a
+href="https://wiki.gnome.org/action/show/GettingInTouch/Bugzilla/GettingTraces";>Getting
+Stack Traces</a>.
 
 #### What is the best way to submit a patch?
 
 The best way to submit a patch is to open a bug report in Gitlab and
-attach the patch there along with a description of what it does and why
-it should be applied.
+attach the patch there, or create a merge request, along with a
+description of what it does and why it should be applied.
 
 An introduction to how this is done can be found in the
-<ulink
-url="http://www.gimp.org/bugs/howtos/submit-patch.html";>
-How To Create and Submit a Patch</ulink> document.
+<a
+href="http://www.gimp.org/bugs/howtos/submit-patch.html";>
+How To Create and Submit a Patch</a> document.
 
 #### What is the preferred coding style used in GIMP?
 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]