GNOME.org
 

[gimp-web-devel/hugo] content: update FAQ.

commit 8593f5cee774cad49595842a1a3b5aee0047f7be
Author: Jehan <jehan girinstud io>
Date:   Sun Aug 7 20:01:07 2022 +0200

    content: update FAQ.
    
    I have fixed some obviously outdated info, removed some (e.g. the whole
    part on Bugzilla), rewritten a bit and even added one question (about
    API breakage for GIMP 3.0).
    
    It is still far from perfect and this FAQ would deserve a bit more love
    and more simplification (e.g. maybe using more links to various
    subsections rather than re-writing the same info again and again on
    various parts of the same website, or even on different websites).
    
    Let's say it's a first step.

 content/faq.md | 365 +++++++++++++++++++++------------------------------------
 1 file changed, 134 insertions(+), 231 deletions(-)
---
diff --git a/content/faq.md b/content/faq.md
index 7770b57..679a62b 100644
--- a/content/faq.md
+++ b/content/faq.md
@@ -16,48 +16,47 @@ regarding development of the GIMP.
 
 GIMP development is coordinated by Wilber the GIMP along
 with a loosely knit team of GIMP developers.  The
-developers can be reached through the GIMP developer
-<olink targetdocent="lists">mailing list</olink>.
+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 Bugzilla.  Pick a
+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?
 
-After helping with a couple of bugs, people will start to
-recognize your immense talent, and you will be on your way
-to becoming a GIMP hacker.  Any time you feel able, you
-can pick a smaller enhancement request and have a go at
-implementing it.  It's that easy.
+The [Core Development](/core_developers/) section is where you want to
+start.
 
 #### Where can I discuss GIMP development?
 
-There are several <olink targetdocent="lists">mailing
-lists</olink> associated with the GIMP project.
-Developments related issues can be brought up on the GIMP
-Developer mailing list.
+Developments related issues can be brought up on the [GIMP
+Developer mailing
+list](https://www.gimp.org/discuss.html#mailing-lists),
+[IRC](https://www.gimp.org/discuss.html#irc-matrix) and the [bug
+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
-<ulink url="irc:://irc.gimp.org:6667/#gimp">irc.gimp.org</ulink>.
+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, also
-referred to as <olink
-targetdocent="gimpcon">GIMPCon</olink>.
+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.
+
+See the [Conferences](/conferences/) section.
 
 #### Where can I find documentation for the GIMP API?
 
-You can pass <command>--enable-gtk-doc</command> to the gimp
-`configure` script.  This requires having
-<ulink url="ftp://ftp.gtk.org/pub/gtk-doc/";>gtk-doc</ulink>
-installed.  After running <command>make</command> you can
-find the GIMP API reference in the
-`devel-docs` directory.
+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.
 
 Pre-generated API documentation is included in the
 official GIMP tarballs.
@@ -65,7 +64,7 @@ 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
-<ulink url="api/2.0/">here</ulink>.
+[here](api/2.0/).
 
 #### How do I make a stack trace?
 
@@ -84,9 +83,9 @@ Stack Traces</ulink>.
 
 #### What is the best way to submit a patch?
 
-The best way to submit a patch is to open a bug report in
-Bugzilla and attach the patch there along with a
-description of what it does and why it should be applied.
+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.
 
 An introduction to how this is done can be found in the
 <ulink
@@ -95,20 +94,11 @@ How To Create and Submit a Patch</ulink> document.
 
 #### What is the preferred coding style used in GIMP?
 
-We encourage you to follow the GIMP coding style
-throughout the GIMP project.  For the core components
-(application and libs) this coding style is enforced.  The
-GIMP coding style is defined as follows:
-
-* Function names are lowercase, words separated by underscores.
-* Macros and enums are all uppercase, words separated by underscores
-* Types are all words capitalized, no separators between words.
-* All functions in header files need to be prototyped.
-* Indentation rules are GNU coding style, in particular:
-  * 2 characters indentation level
-  * Do not use tabs (of course your editor can use tabs, but it should write them to file as 8 spaces each).
-  * Opening brackets are on a new line and indented one level.
-  * Function header have the return type on one line, the name starting in the first column of the following 
line.  All parameters are prototyped and there's a new line for each.
+We encourage you to follow the [GIMP coding style as per the linked
+document](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/CODING_STYLE.md)
+throughout the GIMP project.
+Nowadays this coding style is enforced for every new code in the
+official repositories.
 
 Try to make use of GLib's object system as much as
 possible.  Do not create wrappers around functions of
@@ -131,55 +121,40 @@ url="HACKING">HACKING</ulink>.
 
 #### How can I configure my editor for this coding style?
 
-Your editor will not be able to do everything for you, but
-you can configure most editors so that they use two spaces
-for indentation, use spaces instead of tabs, etc.
-
-* If you are using Emacs, you can insert the following settings into your `~/.emacs` file:
-
-```
-;; Merge this into your custom-set-variables section if you already have one
-(custom-set-variables
-;; Syntax highlighting
-'(global-font-lock-mode t nil (font-lock))
-'(show-paren-mode t nil (paren))
-)
-;; use UTF-8 by default
-(prefer-coding-system 'mule-utf-8)
-;; use the GNU style for C files, spaces instead of tabs, highlight bad spaces
-(setq c-mode-common-hook '(lambda () (c-set-style "gnu")
-                (setq indent-tabs-mode nil)
-                (setq show-trailing-whitespace t))) ]]></programlisting>
-```
-
-* If you are using Vim, you can insert the following settings into your `~/.vimrc` file:
-
-```
-syn on           " syntax highlighting
-set expandtab    " use spaces instead of tabs
-set shiftwidth=2 " default indentation is 2 spaces ]]></programlisting>
-```
-
-* If you are using another editor and you know how to configure it correctly, please tell us about it on the 
GIMP developer <olink targetdocent="lists">mailing list</olink> so that we can update this FAQ.
+We provide [configuration files for a few
+editors](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/CODING_STYLE.md#code-editor-integrated-development-environment-ide)
+and welcome more configuration files for anyone wishing to contribute
+one for their favorite editor or Integrated Development Environment
+(IDE).
 
 #### Who coordinates the GIMP translation efforts?
 
 Any help with translations is appreciated.  If you want to
 help, please get in contact with the people from the
-<ulink
-url="http://developer.gnome.org/projects/gtp/";>GNOME
-Translation Project</ulink> who coordinate all translation
-efforts for projects hosted in the GNOME GIT repository.
+[GNOME Translation Project](https://wiki.gnome.org/TranslationProject)
+who coordinate all translation efforts for projects hosted in the GNOME
+GIT repository.
 
-More information about GIMP and localisation can be found
-in the file <ulink url="README.i18n">README.i18n</ulink>.
+Translations is organized by teams for each language. The recommended
+way is therefore to contact the [specific team for your
+language](https://l10n.gnome.org/teams/) (each team may have different
+rule, their dedicated page will give you specifics).
 
+Exceptionally if no team exists for your language already, you may
+propose to [create a new
+one](https://wiki.gnome.org/TranslationProject/StartingATeam).
+
+Note that you usually don't need to get in touch with developers to
+start and translate GIMP since everything happens through GNOME
+localization infrastructure. Yet if you want to get in touch with us or
+if you have any problem with the aforementionned procedure, feel free to
+[get in touch with developers](https://www.gimp.org/discuss.html).
 
 #### How can I support GIMP development?
 
-By using GIMP and reporting any bugs you find to
-<ulink url="http://bugzilla.gnome.org/";>Bugzilla</ulink>
-you're helping a great deal.  But there are other
+By using GIMP and reporting any bugs you find in
+[Gitlab](https://gitlab.gnome.org/GNOME/gimp/-/issues),
+you're helping a great deal. But there are other
 non-technical ways of supporting the development of The
 GIMP as well.
 
@@ -190,43 +165,47 @@ freshened up, documentation needs to be added for new
 functionality, the web site needs to get a new lick of
 paint and so on.
 
-If you're interested in helping out you should drop an
-e-mail to the GIMP developer <olink
-targetdocent="lists">mailing list</olink> offering your
+If you're interested in helping out you should [get in touch with
+developers](https://www.gimp.org/discuss.html), offering your
 help.
 
+Last but not least, [donating to GIMP](https://www.gimp.org/donating/)
+supports the development, especially as several developers are trying
+and make a living by developing GIMP full-time.
+
 ## Plug-In Development
 
 #### Is there a plug-in template available?
 
-Yes. An official GIMP plug-in template is available in
-the <ulink
-url="http://git.gnome.org/cgit/gimp-plugin-template/";>gimp-plugin-template
-</ulink> git module.  Snapshots are available at <ulink
-url="ftp://ftp.gimp.org/pub/gimp/plugin-template/";>ftp.gimp.org</ulink>.
+Yes. An [official GIMP plug-in template is
+available](/resource_developers/plug-in-template/).
+
+Note however that this template is old and likely quite outdated,
+regarding modern recommendation. We are planning to improve
+documentation and help for plug-in developers soon.
 
 #### How about a Script-Fu template?
 
-Yes.  Simon Budig has written a fill-in-the-blanks
-Script-Fu template which is available <ulink
-url="http://www.home.unix-ag.org/simon/files/script-fu-template.scm";>here</ulink>.
+Yes. Simon Budig has written a fill-in-the-blanks
+Script-Fu template which is available
+[here](http://www.home.unix-ag.org/simon/files/script-fu-template.scm).
 
 #### How do I get my plug-in included in the GIMP?
 
-The best way to make your plug-in available to the World
-is to submit it to <ulink
-url="http://registry.gimp.org/";>the GIMP Plug-In
-Registry</ulink>.
-
 If you are certain that your plug-in will be useful to all
 GIMP users, then you can ask the GIMP developers to
-consider it for inclusion in future GIMP release.  The
-best way to do that is to suggest it on the GIMP developer
-<olink targetdocent="lists">mailing list</olink> or to
-open an enhancement request in Bugzilla. However, we would
-like to limit the number of plug-ins included in the
-standard distribution and encourage all users to use the
-registry.
+consider it for inclusion in future GIMP release by creating a [merge
+request](https://gitlab.gnome.org/GNOME/gimp/-/merge_requests).
+
+However, we have been trying to limit the number of plug-ins included in
+the standard distribution to the most common usage only. Therefore do
+not expect this to to happen if your proposed plug-in caters to a
+specific usage.
+
+We used to have a registry for third-party developers to publish their
+plug-ins and other resources. This registry is now gone as it was using
+deprecated technology and was becoming a source of problems. Some work
+is in-progress to get a new platform for third-party resources.
 
 #### How do I debug a GIMP plug-in?
 
@@ -240,9 +219,7 @@ To address this issue, libgimp has some hooks controlled
 by the `GIMP_PLUGIN_DEBUG` environment
 variable.  The idea is that you can attach a debugger to
 the pid of the plug-in you want to debug.  The process is
-described in the file <ulink
-url="debug-plug-ins.txt">debug-plug-ins.txt</ulink>.
-
+described in the file 
[debug-plug-ins.txt](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/debug-plug-ins.txt)
 
 #### Will the plug-in I compiled against 2.0 work with GIMP 2.2 or 2.4?
 
@@ -255,10 +232,29 @@ If the plug-in you compiled for 2.0 does not work with 2.2
 or 2.4, there is one change which has been made which is
 not backwards compatible, since the old behaviour was
 considered incorrect. If you create a temporary drawable,
-using for example gimp_layer_new(), you are now required
+using for example `gimp_layer_new()`, you are now required
 to add it to an image before calling any functions with
 the drawable as an argument.
 
+#### Will my 2.x plug-in work with GIMP 3.0?
+
+A major release is the occasion to fix wrong design choices, therefore
+the API compatibility was broken. It means some part of your plug-in
+will have to be rewritten.
+
+What you need to rewrite is mostly infrastructure code (how the plug-in
+is registered) and a few calls to glue internal logics and your plug-in
+logics. For instance, since GIMP 3.0 finally allows multiple selection
+of layers, various functions will now use or return a list of layers
+instead of a single layer.
+In the end, porting your code may be frightnening but it can be done
+very quickly.
+
+The 2.x series lasted nearly 20 years and we care a lot about API
+backward compatibility. So feel assured that such API breakage won't
+happen all the time. Once again, GIMP 3.2 will be backward compatible
+with GIMP 3.0 and so on.
+
 ## GIT
 
 #### What should I put in the commit message when doing a git commit?
@@ -277,35 +273,32 @@ Bugzilla bug page.
 
 #### What is GEGL?
 
-GEGL is the <ulink url="http://www.gegl.org";>Generic
-Graphical Library</ulink>.  It is supposed to replace the
-handling of various image processing tasks in GIMP in
-a not too distant future (planned for GIMP 2.6).
+GEGL is the [Generic Graphical Library](http://www.gegl.org).  It is
+replaced the handling of various image processing tasks in
+GIMP, starting from 2.8. Its usage became more pervasive since GIMP
+2.10.
 
-#### What will GEGL be able to do?
+#### What is GEGL able to do?
 
-GEGL will be a general image processing library.  It uses
-a directed acyclic graph, a DAG, to represent image
-processing operations.  In the DAG, images are edges, and
-operations are nodes.  It takes advantage of this DAG to
-minimize regions which are processed, provide efficient
-caching of operations, and efficient redrawing when a
-parameter of the graph changes.
+GEGL is be a general image processing library.  It uses a directed
+acyclic graph, a DAG, to represent image processing operations.  In the
+DAG, images are edges, and operations are nodes.  It takes advantage of
+this DAG to minimize regions which are processed, provide efficient
+caching of operations, and efficient redrawing when a parameter of the
+graph changes.
 
-GEGL should also be independent of the data type being
-processed and will be able to handle high bit depth
-images, ICC profiles and parallel processing of image
-tiles.
+GEGL is also independent of the data type being processed and is able to
+handle high bit depth images, ICC profiles and parallel processing of
+image tiles.
 
 #### What does all that gibberish mean for GIMP?
 
-Many highly requested features of the GIMP will be easier
-to do using GEGL.  Layer effects, layer groups, and
-adjustment layers are quite easily represented (and
-efficiently calculated) using the DAG organization of GEGL.
-CMYK and high bit depth support will be easier because
-GEGL does not make the same assumptions about color spaces
-and data types that the GIMP does.
+Many highly requested features of GIMP are easier to do using GEGL.
+Layer effects, layer groups, and adjustment layers are quite easily
+represented (and efficiently calculated) using the DAG organization of
+GEGL.
+CMYK and high bit depth support are easier because GEGL does not make
+the same assumptions about color spaces and data types that GIMP does.
 
 The reusability of image processing operations means that
 plug-ins will be able to be designed in a much more modular
@@ -313,122 +306,32 @@ way.  The brush system will be able to become more
 flexible, especially when filter plug-ins are able to be
 used as procedural brush plug-ins.
 
-## Bugzilla
-
-#### What is Bugzilla?
-
-The GIMP project uses <ulink
-url="http://bugzilla.gnome.org";>GNOME Bugzilla</ulink> for
-tracking of bug reports, enhancement requests etc.
-
-A beginners tutorial describing how to report a bug can be
-found in the <ulink
-url="http://www.gimp.org/bugs/howtos/bugzilla.html";>
-How To Report GIMP Bugs</ulink> document.
-
-An easy to use interface to reporting GIMP bugs can be
-found on <ulink
-url="http://bugs.gimp.org";>bugs.gimp.org</ulink>.
-
-#### What is the meaning of the NEEDINFO status code inBugzilla?
-
-If the status of a bug is changed to NEEDINFO it means the
-GIMP developers need more information from the bug
-reporter in order to resolve the bug.
-
-More information about the meaning of the Bugzilla status
-field codes can be found in <ulink
-url="http://bugzilla.gnome.org/page.cgi?id=bug-status.html";>
-A Bug's Life Cycle</ulink>.
-
-#### What is the best way to refer to a bug in Bugzilla?
-
-The best way to refer to a bug is <quote>bug
-#nnnnn</quote>, where nnnnn is the bug number.  Using
-<quote>bug</quote> before the number allows Bugzilla to
-link to the corresponding bug report automatically.  Using
-<quote>#</quote> before the number is optional for
-Bugzilla but makes it easier to locate references to bug
-reports in the ChangeLog or in e-mails.
-
-When referencing multiple bugs, it is better to be a bit
-redundant by writing <quote>bug #xxxxx, bug #yyyyy and bug
-#zzzzz</quote> instead of <quote>bugs #xxxxx, #yyyyy and
-#zzzzz</quote> in order to allow Bugzilla to link all bugs
-automatically.
-
-#### What is the proper way of handling duplicate bug reports?
-
-A bug report describing the same bug as a previous bug
-report should be marked as DUPLICATE of the older one.
-In some exceptional cases, it is possible to mark an old
-bug report as DUPLICATE of a newer one (e.g., when the
-newer bug report has a significantly better description
-than the older one).
-
-Another exception is when the same person submits the same
-bug report several times (same description): in this case,
-it is better to mark the additional copies of the bug
-report as INVALID in order to avoid inflating the
-statistics about the number of duplicates.
-
-#### What is the proper way of marking a bug as RESOLVED?
-
-When fixing a bug, always mention the bug number in the
-commit message.  Once the changes are in git, paste the
-relevant part of the commit message (or all of it) in the
-comment field and mark the bug as RESOLVED FIXED.
-These cross-references help a lot when trying to find
-when a bug was fixed, its relations to other bugs, and
-potential regressions.
-
-A bug that is fixed in git or in an unstable release
-should be marked as RESOLVED FIXED.  Optionally, the
-reporter or someone other than the one who fixed the bug
-can mark it as VERIFIED after some testing.  When the fix
-is part of a stable release, it can be marked as CLOSED.
-
-This is explained further in <ulink
-url="http://bugzilla.gnome.org/page.cgi?id=bug-status.html";>A
-Bug's Life Cycle</ulink> except for the difference between
-stable and unstable releases.
-
 ## Miscellaneous
 
 #### Where can I learn more about the GObject system used by GIMP?
 
-The
-<ulink url="http://library.gnome.org/devel/gobject/stable/";>GObject
-documentation</ulink> has a
-nice <ulink url="http://library.gnome.org/devel/gobject/stable/howto-gobject.html";>tutorial</ulink> that you 
might want to have a look at.
+The [GObject documentation](https://docs.gtk.org/gobject/) has a
+nice [tutorial](https://docs.gtk.org/gobject/tutorial.html) that you
+might want to have a look at.
 
 #### Where can I learn more about color spaces etc?
 
-Charles Poynton has collected a set of <ulink
-url="http://www.poynton.com/ColorFAQ.html";>Frequently
-Asked Questions about Color</ulink>.
+Charles Poynton has collected a set of [Frequently Asked Questions about
+Color](http://www.poynton.com/ColorFAQ.html).
 
 #### Where can I learn more about image manipulation algorithms?
 
-A good source of information is the
-comp.graphics.algorithms list of <ulink
-url="http://www.faqs.org/faqs/graphics/algorithms-faq/";>Frequently
-Asked Questions</ulink>.
+A good source of information is the `comp.graphics.algorithms` list of
+[Frequently Asked Questions](http://www.faqs.org/faqs/graphics/algorithms-faq/).
 
 #### Is there a GIMP user FAQ available?
 
-There is no user FAQ available at the moment.  However
-there has been discussions about creating one.  If you
-would like to help with this please drop a mail on the
-GIMP developer <olink targetdocent="lists">mailing
-list</olink>.
+Please see the [User FAQ on `gimp.org`](https://www.gimp.org/docs/userfaq.html).
 
 #### How can I contribute to this FAQ?
 
-If you would like to contribute to this FAQ, send an
-e-mail to the GIMP developer [mailing list](lists) with the
-exact text you think should be included (both question and
-answer).
+If you would like to contribute to this FAQ, propose a merge request on
+the [git
+repository](https://gitlab.gnome.org/Infrastructure/gimp-web-devel/).
 
 With your help this FAQ will grow and become more useful.
-
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]