[gimp-web-devel] content: various styling/organization fixes.
- From: Jehan <jehanp src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gimp-web-devel] content: various styling/organization fixes.
- Date: Sat, 15 Oct 2022 18:05:59 +0000 (UTC)
commit f3e3cdba66c2430b130a1c2f8dd5daa4c6ce3df3
Author: Jehan <jehan girinstud io>
Date: Sat Oct 15 19:55:12 2022 +0200
content: various styling/organization fixes.
These are various issues I noticed when re-verifying all pages we published in
the new dev website:
- Making show_subs to false for gimpcon/2003/ because it's redundant with
in-text links.
- Fixing heading levels in various documents (wrong levels made obvious by the
recent table of contents feature).
- Moving graphic_tablets_support to specifications/. It doesn't make much sense
to have it as a base core documents. But it makes much more sense to make it a
document to discuss how we want tablet support to be in GIMP (in other words:
a spec, or at least work document).
- Removing kinda useless toc in resource/api/.
- Styling a bit the writing-a-plug-in/ tutorial and fixing licensing image and
links. Also fixing the links to "next part".
- Moving problems_and_solutions to base core/. It's not specifically a setup
document, more a generic database of common development issues, when they
don't deserve their own documents.
content/conferences/gimpcon/2003/_index.md | 1 +
content/conferences/gimpcon/2003/minutes-1.md | 14 ++---
content/conferences/gimpcon/2003/minutes-2.md | 16 +++---
content/conferences/gimpcon/2003/minutes-3.md | 12 ++---
content/core/algorithm/flood.md | 6 +--
..._and_solutions.md => problems_and_solutions.md} | 22 ++++----
.../graphic_tablets_support.md | 6 +++
content/resource/api.md | 1 +
content/resource/writing-a-plug-in/1.md | 37 +++++--------
content/resource/writing-a-plug-in/2.md | 60 +++++++++-------------
content/resource/writing-a-plug-in/3.md | 27 +++++-----
content/resource/writing-a-plug-in/_index.md | 2 +-
12 files changed, 92 insertions(+), 112 deletions(-)
---
diff --git a/content/conferences/gimpcon/2003/_index.md b/content/conferences/gimpcon/2003/_index.md
index 7f0df3d..b62be4c 100644
--- a/content/conferences/gimpcon/2003/_index.md
+++ b/content/conferences/gimpcon/2003/_index.md
@@ -4,6 +4,7 @@ abbrev = "GIMPCon 2003"
description = "Chaos Communication Camp, Berlin, Germany"
summary = "Chaos Communication Camp, Berlin, Germany"
date = "2003-08-07"
+show_subs = false
+++
## GIMPCon 2003
diff --git a/content/conferences/gimpcon/2003/minutes-1.md b/content/conferences/gimpcon/2003/minutes-1.md
index 1b098f2..5a33e5d 100644
--- a/content/conferences/gimpcon/2003/minutes-1.md
+++ b/content/conferences/gimpcon/2003/minutes-1.md
@@ -27,7 +27,7 @@ Topic discussion, in approximate chronological order:
* [General stuff about CVS, Bugzilla](#general-stuff-about-bugzilla-and-cvs)
* [Communication](#communication)
-#### The GIMP Foundation
+## The GIMP Foundation
The idea of a foundation was proposed. Lots of ideas were thrown
about as to what kind of remit it would have. If created, the
@@ -48,7 +48,7 @@ This led onto a discussion of whether the foundation would be
responsible for setting release dates, or whether we would have
a separate...
-#### Release Manager
+## Release Manager
The general consensus (more on that later) was that a release
manager is a good thing. There do seem to be a few different
@@ -81,7 +81,7 @@ out CVS commits OK, for example?
So we started talking about how to get contentious decisions
made.
-#### Decision making (or lack of it)
+## Decision making (or lack of it)
Currently, there are two ways to get something done in the
GIMP. First, you can write decent code and patches for a while,
@@ -122,7 +122,7 @@ enough standing and authority to post one of these thread-ending
summaries? Some discussion is going to be had on that over the
weekend.
-#### General stuff, about Bugzilla and CVS
+## General stuff, about Bugzilla and CVS
We talked about various ways of improving the way we use these
tools. First is whether it makes sense for us to have module
@@ -153,7 +153,7 @@ given group should know everyone else in the group, and know
more or less that when an issue gets in, it will be handled by
at least one person.
-#### Communication
+## Communication
It was agreed that we need to communicate better (that's a
no-brainer, really). For a start, every developer should be
@@ -166,14 +166,14 @@ be discussed on the user list.
Basically, we're going to talk a lot more about how the
developers can interface better with the users.
-#### Decisions
+## Decisions
Not too many of these... we will have a release manager, but we
need to define exactly what his/her remit will be. And who it
will be. We agreed that the "5 days and it's dead" rule for threads
makes sense, so that will be done.
-#### Future
+## Future
1. Roadmap - rough release schedule, we will have a first draft today.
2. GIMP Foundation - we need to define its responsibilities, set up election rules, and get this set up. The
principle of the foundation is more or less agreed.
diff --git a/content/conferences/gimpcon/2003/minutes-2.md b/content/conferences/gimpcon/2003/minutes-2.md
index 5b1806a..e2720e6 100644
--- a/content/conferences/gimpcon/2003/minutes-2.md
+++ b/content/conferences/gimpcon/2003/minutes-2.md
@@ -29,7 +29,7 @@ Topic discussion, in approximate chronological order:
* [GIMP Foundation](#gimp-foundation)
* [Release manager](#release-manager)
-#### Features required for 2.0
+## Features required for 2.0
There was quite a lot of talk on what was required for a 2.0
release. It was agreed that a pre-release should have feature
@@ -47,7 +47,7 @@ necessary are:
1. Web-site (again, more on this later)
1. Some libgimp changes which need to be made now so that we can havebinary compatibility across a 2.2
release
-#### Documentation
+## Documentation
We felt that with pre-releases, the documentation will become
more complete. There should, however, be an effort to actively
@@ -73,7 +73,7 @@ the help team.
We also need to have the docs browsable online so that if people
want to browse them they can.
-#### Web-site
+## Web-site
The new site should switch over to www.gimp.org soon. There will
obviously be quite a bit of pain involved as content gets added
@@ -86,7 +86,7 @@ suggested to do it even earlier than that, in the region of 2 to
It was also discussed whether it was a good idea to have a
separate coordinator for the website.
-#### Roadmap
+## Roadmap
As an approximate set of ideals, it was agreed that we want
this: 2.0pre1 very soon, 2.0 soon, 2.2 next year, and GEGL
@@ -111,7 +111,7 @@ little more than 2 weeks work, and people have real lives. So 6
weeks was felt to be a reasonable amount of time to have the
path tool and the help browser in place.
-#### Bugs
+## Bugs
The developer release will also be a prelude to a bug week. We
would like people (that's you, in particular) to actively work
@@ -145,7 +145,7 @@ leave more time for programmers to program.
This leads us on to...
-#### Task list
+## Task list
There are lots of non-technical jobs that need doing around the
gimp-docs, website, bugzilla triage, internationalisation,
@@ -168,7 +168,7 @@ people looking at bugzilla regularly. Then again, if there were
a link to a bugzilla query on the webpage marked "GIMP
TODO list" we could get that for free.
-#### GIMP Foundation
+## GIMP Foundation
Basically, we're agreed this is a good idea to have some kind of
public face people and companies can contribute to. There is no
@@ -204,7 +204,7 @@ the foundation then gets sued.
In brief, it's being set up with a very narrow remit, with the
possibility to expand later if it is felt that there is a need.
-#### Release manager
+## Release manager
The responsibilities are:
diff --git a/content/conferences/gimpcon/2003/minutes-3.md b/content/conferences/gimpcon/2003/minutes-3.md
index b02440e..c8715a9 100644
--- a/content/conferences/gimpcon/2003/minutes-3.md
+++ b/content/conferences/gimpcon/2003/minutes-3.md
@@ -26,7 +26,7 @@ the following topics were discussed:
* [List of open tasks](#list-of-open-tasks)
* [Mailing lists](#mailing-lists)
-#### How to get new developers?
+## How to get new developers?
Like in any Free Software project, developers are leaving from
time to time to pursue other projects. And from time to time,
@@ -52,7 +52,7 @@ involved?". It should be easy for potential new
developers to see where to start and how they can help. More on
that below.
-#### Do we need binary distributions?
+## Do we need binary distributions?
There was a discussion about binary distributions. This may help
people to try some versions of the GIMP (especially the
@@ -67,7 +67,7 @@ are providing binaries for various platforms.
It would be very nice to have Windows binaries for the
development version.
-#### Is Bugzilla too hard to use for new users?
+## Is Bugzilla too hard to use for new users?
It was suggested to make it easier for users to submit bug
reports, for example by having an e-mail address to which bug
@@ -91,7 +91,7 @@ a small problem with the GNOME2 keyword that prevents the open
GIMP bugs from being displayed to the user and we should try to
get this fixed.
-#### List of open tasks
+## List of open tasks
There are many open bug reports or proposals for enhancements
that would be relatively easy to fix or implement. We should
@@ -113,7 +113,7 @@ direct links to the corresponding bug reports. The second
solution may require a bit more work because it would have to be
maintained by someone, but it might be a bit easier to use.
-#### Mailing lists
+## Mailing lists
Sometimes, there is a lack of communication between users and
developers of The GIMP. After some discussion, it was decided
@@ -138,7 +138,7 @@ gimp.de, etc. The description of the mailing lists should
encourage people to subscribe to both the users and developers
lists.
-#### Summary
+## Summary
We hope that the next stable release will attract new
developers. This has been the case when 1.0 and 1.2 were
diff --git a/content/core/algorithm/flood.md b/content/core/algorithm/flood.md
index 39e52ba..6a5e2f4 100644
--- a/content/core/algorithm/flood.md
+++ b/content/core/algorithm/flood.md
@@ -140,7 +140,7 @@ transformation when dealing with vertical segments, as explained later.
Each segment is processed using the following steps.
-#### 1. Vertical propagation
+### 1. Vertical propagation
The segment's pixels are updated, using the above transformation rule, considering only the corresponding
neighboring pixels of the source segment. During the process, we inspect which of the segment's pixels
actually changed, and create a
@@ -163,7 +163,7 @@ becomes important in the next step.
dirty ranges.
```
-#### 2. Horizontal propagation
+### 2. Horizontal propagation
The segment's pixels are updated, considering only their left and right neighbors, using the two-pass process
described above. Though semantically equivalent, this process slightly more intricate than the one described
above, since we use the
@@ -227,7 +227,7 @@ in our case). This condition is still met at the end of the first pass.
One final detail: each dirty range has an associated ''modified'' flag, which is initially cleared. If,
during the above process, the range is
extended, or its existing pixels are modified, then its ''modified'' flag is set. This flag is used by the
next step.
-#### 3. Distribution
+### 3. Distribution
The changes to the current segment's water level may affect the two neighboring rows. For each dirty range,
we push two new
segments into the queue -- one for each neighboring row -- using the current row as their source segment.
diff --git a/content/core/setup/Problems_and_solutions.md b/content/core/problems_and_solutions.md
similarity index 97%
rename from content/core/setup/Problems_and_solutions.md
rename to content/core/problems_and_solutions.md
index 2406b93..9b66a44 100644
--- a/content/core/setup/Problems_and_solutions.md
+++ b/content/core/problems_and_solutions.md
@@ -935,7 +935,7 @@ Problem
## Translate
-#### Lots of merge conflicts in GIMP master
+### Lots of merge conflicts in GIMP master
Problem
: I'm translating on the current production branch of GIMP (`gimp-2-10`, etc.) and on `master`. I'd like to
cherry-pick my changes from the production branch to the master branch. But I get lots of merge conflicts and
changes I never introduced.
@@ -946,7 +946,7 @@ Cause
Solution
: Commit your translation updates directly into the master branch or try to merge your translation branch
into the master branch.
-#### See also
+### See also
* [GEGL Developer mailing list](https://mail.gnome.org/archives/gegl-developer-list/)
* <a class="external text" href="irc://irc.gimp.org/#gegl" rel="nofollow">GEGL IRC channel</a>
@@ -970,7 +970,7 @@ Warnings and errors displayed in a terminal/console in which you started GIMP fr
Many are just clutter, that make it hard to find severe errors from code you are testing.
-#### 'GEGL-Message: 14:09:17.687: Module '/usr/local/lib/x86_64-linux-gnu/libgegl-npd-0.4.so' load error:
Missing gegl_module_query() symbol ?'
+### 'GEGL-Message: 14:09:17.687: Module '/usr/local/lib/x86_64-linux-gnu/libgegl-npd-0.4.so' load error:
Missing gegl_module_query() symbol ?'
Problem
: GIMP starts, but the terminal displays many messages similar to the above, when plugins are loaded.
@@ -985,7 +985,7 @@ reference the top GEGL directory, not just its parent. Referencing the
parent is sufficient for GIMP to start, but not for plugins to load
without these warnings.
-#### GIMP fails to start with error, 'GIMP requires the GEGL operation "gegl:alien-map"'
+### GIMP fails to start with error, 'GIMP requires the GEGL operation "gegl:alien-map"'
Problem
: GIMP starts fails to start, with the message above.
@@ -996,7 +996,7 @@ Cause
Solution
: See above under 'Building'
-#### A plugin fails to appear in the menus, with error like "GIMP-WARNING: gimp-2.xx: gimp_wire_read():
error"
+### A plugin fails to appear in the menus, with error like "GIMP-WARNING: gimp-2.xx: gimp_wire_read(): error"
Problem
: GIMP starts, but a plugin does not appear in the GIMP menus as expected, and the terminal shows the above
message.
@@ -1015,7 +1015,7 @@ To debug the flawed plugin, you can use print statements.
An interpreted plugin may fail very early in its text, for example in the hashbang i.e. `#!/usr/bin/env
python3` statement on the first line,
or in an import statement.
-#### Chain of python exceptions beginning with gi.RepositoryError: Typelib file for namespace 'Gegl',
version '0.4' not found
+### Chain of python exceptions beginning with gi.RepositoryError: Typelib file for namespace 'Gegl', version
'0.4' not found
Problem
: On startup, GIMP starts but shows a long chain of Python exceptions. The root exception (the first in the
list) is as above. Affects loading of plugins.
@@ -1032,7 +1032,7 @@ you use it.)
The typelibs for GIMP, GEGL, and babl might be on different paths (as in the example).
-#### Gtk-Message: 19:04:46.797: Failed to load module "canberra-gtk-module"
+### Gtk-Message: 19:04:46.797: Failed to load module "canberra-gtk-module"
Problem
: Terminal often displays message like above. Does not affect operation, except sounds may be missing?
@@ -1061,7 +1061,7 @@ self-built one may have been built differently), you may also decide to
ignore the message, as it's harmless (unlike you needed to use this
module, but chances are low this would ever be needed for GIMP).
-#### (gimp-2.99:xx): dbind-WARNING **: 09:35:43.023: Couldn't register with accessibility bus:
+### (gimp-2.99:xx): dbind-WARNING **: 09:35:43.023: Couldn't register with accessibility bus:
Problem
: Terminal often shows message like above. Does not affect operation, unless you need accessibility i.e.
are visually or hearing impaired.
@@ -1072,7 +1072,7 @@ Cause
Solution
: In your environment: `export NO_AT_BRIDGE=1`
-#### luajit: ...mp/2.99/plug-ins/goat-exercise-lua/goat-exercise-lua.lua:22: module 'lgi' not found:
+### luajit: ...mp/2.99/plug-ins/goat-exercise-lua/goat-exercise-lua.lua:22: module 'lgi' not found:
Problem
: On startup, terminal shows a message that begins like above and ends with "GIMP-WARNING: gimp-2.99:
gimp_wire_read(): error".
@@ -1085,7 +1085,7 @@ Cause
Solution
: Install the package.
-## On Ubuntu: Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed
(error == NULL): Icon 'image-missing' not present in theme Symbolic (gtk-icon-theme-error-quark, 0====
+### On Ubuntu: Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed
(error == NULL): Icon 'image-missing' not present in theme Symbolic (gtk-icon-theme-error-quark, 0====
Problem
: On Ubuntu (only?), when using a plugin that opens a Gtk3 file chooser widget, terminal shows a message as
above, and plugin crashes.
@@ -1096,7 +1096,7 @@ Cause
Solution
: Install the package. If you are not building GIMP yourself, apparently this issue is fixed by the
packaging of GIMP having a dependency on package `gnome-icon-theme`.
-#### (gimp-2.99:xx): dconf-WARNING **: 13:59:42.430: failed to commit changes to dconf: Failed to execute
child process ?dbus-launch? (No such file or directory)
+### (gimp-2.99:xx): dconf-WARNING **: 13:59:42.430: failed to commit changes to dconf: Failed to execute
child process ?dbus-launch? (No such file or directory)
Problem
: The message appears as you start a plugin. It seems harmless unless you have configured GLib to stop on
warnings, or if you want to use the services of [dbus](https://en.wikipedia.org/wiki/D-Bus)
diff --git a/content/core/graphic_tablets_support.md b/content/core/specifications/graphic_tablets_support.md
similarity index 96%
rename from content/core/graphic_tablets_support.md
rename to content/core/specifications/graphic_tablets_support.md
index 5c48ee2..5e8901a 100644
--- a/content/core/graphic_tablets_support.md
+++ b/content/core/specifications/graphic_tablets_support.md
@@ -4,6 +4,12 @@ Author: "GIMP team"
Date: 2022-09-11
---
+ℹ️ **Note**: the current document so far is mostly "current state" information on
+tablet support in GIMP (stable and development). Ideally we should move the
+document into another direction, to be about "how we want tablet support to be".
+Basically it should rather be a specification on stylus and gesture support (and
+related technologies) in GIMP.
+
## Stylus usage
### GIMP 2.10
diff --git a/content/resource/api.md b/content/resource/api.md
index 70b53e4..5647da7 100644
--- a/content/resource/api.md
+++ b/content/resource/api.md
@@ -4,6 +4,7 @@ date = "2022-08-07"
abbrev = "api-ref"
description = "GIMP Reference Manuals"
weight = 1
+toc = false
+++
GIMP comes with libraries which can be used by plug-in developers to
diff --git a/content/resource/writing-a-plug-in/1.md b/content/resource/writing-a-plug-in/1.md
index c9617fc..daf331e 100644
--- a/content/resource/writing-a-plug-in/1.md
+++ b/content/resource/writing-a-plug-in/1.md
@@ -62,7 +62,7 @@ directory.
Syntax is
-```
+```sh
gimptool-2.0 --install plugin.c or gimptool-2.0 --install-admin plugin.c
```
@@ -80,13 +80,13 @@ like a file saver plug-in.
## Essentials
-```
+```C
#include <libgimp/gimp.h>
```
This header makes all basic plug-in elements available to us.
-```
+```C
GimpPlugInInfo PLUG_IN_INFO = {
init,
quit,
@@ -121,7 +121,7 @@ a pointer to output parameters, then determines if it is
launched in a interactive way or by a script, and does all the
plug-in processing. Its prototype is
-```
+```C
void run (const gchar *name,
gint nparams,
const GimpParam *param,
@@ -144,7 +144,7 @@ startup time, and refreshed only when the plug-in is modified.
For our "Hello, world!" plug-in, the query function will look
like this:
-```
+```C
static void
query (void)
{
@@ -197,7 +197,7 @@ descriptors.
`INDEXED` or `GRAY`, with or without Alpha. So "`RGB*, GRAY*`"
describes RGB, `RGBA`, `GRAY` or `GRAY` image type.
-GIMP_PLUGIN declares this procedure to be external, and not to
+`GIMP_PLUGIN` declares this procedure to be external, and not to
be executed in The GIMP core.
By adding a stub run function now, we can check that our plug-in
@@ -239,7 +239,7 @@ For our test plug-in, we will simply display a dialog containing
a "Hello, world!" message. Thankfully, this is really easy with
GTK+. Our run function could be:
-```
+```C
static void
run (const gchar *name,
gint nparams,
@@ -275,26 +275,15 @@ Have a look at the full [hello.c](hello.c) plug-in code.
## Next part
-In <olink targetdocent="writing-a-plug-in-2">next part</olink>
+In [next part](../2/)
we will go on, making a more useful plug-in that will get its
hands on image data. We will see how to use The GIMP image
architecture to make the plug-in perform better, processing the
image tile by tile.
-<para role="images">
-<ulink url="http://creativecommons.org/licenses/by-nc-sa/2.5/";>
-<mediaobject>
-<imageobject>
-<imagedata fileref="http://creativecommons.org/images/public/somerights20.gif"/>
-</imageobject>
-<textobject>
-<phrase>Creative Commons License</phrase>
-</textobject>
-</mediaobject>
-</ulink>
-
-This work is licensed under a <ulink
-url="http://creativecommons.org/licenses/by-nc-sa/2.5/";>Creative
-Commons Attribution-NonCommercial-ShareAlike 2.5
-License</ulink>.
+[](http://creativecommons.org/licenses/by-nc-sa/2.5/)
+This work is licensed under a [Creative Commons
+Attribution-NonCommercial-ShareAlike 2.5
+License](http://creativecommons.org/licenses/by-nc-sa/2.5/).
diff --git a/content/resource/writing-a-plug-in/2.md b/content/resource/writing-a-plug-in/2.md
index 027f1d7..e1dcecb 100644
--- a/content/resource/writing-a-plug-in/2.md
+++ b/content/resource/writing-a-plug-in/2.md
@@ -35,7 +35,7 @@ x (2r + 1)` matrix.
Last month, we wrote a run() function that did nothing useful.
Let's look again at run() prototype:
-```
+```C
static void run (const gchar *name,
gint nparams,
const GimpParam *param,
@@ -64,16 +64,15 @@ Drawables
To get a GimpDrawable from its identifier, we need the
`gimp_drawable_get()` function:
-```
+```C
GimpDrawable *gimp_drawable_get (gint32 drawable_id);
```
From this structure, one can access drawable data through a
GimpPixelRgn structure, and one can check the drawable type
(RGB, gray level). The full listing of functions available for a
-GimpDrawable can be found <ulink
-url="http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpdrawable.html";>in
-the API</ulink>.
+GimpDrawable can be found [in the
+API](http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpdrawable.html).
Two very important functions for plug-ins are
gimp_drawable_mask_bounds() and gimp_pixel_rgn_init(). The first
@@ -94,7 +93,7 @@ expensive, so we should not use it more than necessary.
The main functions to get and set image data are:
-```
+```C
void gimp_pixel_rgn_get_pixel (GimpPixelRgn *pr,
guchar *buf,
gint x,
@@ -158,7 +157,7 @@ gimp_drawable_detach (drawable);
To be able to try out several different processing methods, we
will delegate the job to a blur() function. Our run() is below.
-```
+```C
static void
run (const gchar *name,
gint nparams,
@@ -204,19 +203,19 @@ run (const gchar *name,
```
There are a few lines here that need to be explained a bit more.
-The call to gimp_progress_init() initialises a progress
+The call to `gimp_progress_init()` initialises a progress
measurement for our plug-in. Later, if we call
-gimp_progress_update(double percent), the percentage given as an
-input parameter will be shown graphically. The run_mode tells us
+`gimp_progress_update(double percent)`, the percentage given as an
+input parameter will be shown graphically. The `run_mode` tells us
whether the plug-in was launched in a way such as we can display
a graphical interface or not. Possible values are
-GIMP_RUN_INTERACTIVE, GIMP_RUN_NONINTERACTIVE or
-GIMP_RUN_WITH_LAST_VALS, which mean the plug-in was executed
+`GIMP_RUN_INTERACTIVE`, `GIMP_RUN_NONINTERACTIVE` or
+`GIMP_RUN_WITH_LAST_VALS`, which mean the plug-in was executed
from The GIMP, from a script, or from the "Repeat last filter"
menu entry.
Regarding the blur algorithm itself, the first version using
-gimp_pixel_rgn_(get|set)_pixel() is found below. Some functions
+`gimp_pixel_rgn_(get|set)_pixel()` is found below. Some functions
in it have not been explained yet.
`gimp_drawable_mask_bounds()` allows calculation of the filter's
@@ -229,14 +228,14 @@ its limits for the processing, and two booleans that
significantly modify the behaviour of the resulting GimpPixelRgn.
The first one tells that "set" operations must be done on shadow
tiles, in order to leave original data as is until
-gimp_drawable_merge_shadow() is called, when all modified data
+`gimp_drawable_merge_shadow()` is called, when all modified data
will be merged. The second one tells that modified tiles should
be tagged "dirty" and sent to the core to be merged. Most of the
time, to read data, one uses FALSE and FALSE for these two
parameters, and to write data, one uses TRUE and TRUE. Other
combinations are possible but seldom used.
-```
+```C
static void
blur (GimpDrawable *drawable)
{
@@ -344,16 +343,16 @@ blur (GimpDrawable *drawable)
## Row processing
Our function has a bug drawback: performance. On a 300x300
-selection, with the timing code uncommented, blur() took 12
+selection, with the timing code uncommented, `blur()` took 12
minutes on my K6-2 350MHz, well loaded with other stuff. To
compare, on the same selection, Gaussian blur took 3 seconds.
If we modify our function to rather use
-gimp_pixel_rgn_(get|set)_row() the result is far better. We
+`gimp_pixel_rgn_(get|set)_row()` the result is far better. We
reduce the timing for the 300x300 selection from 760 seconds to
6 seconds. blur() V2 is below:
-```
+```C
static void
blur (GimpDrawable *drawable)
{
@@ -448,27 +447,14 @@ Have a look at the [slow](myblur1.c) or [fast](myblur2.c) blur complete code.
## Next part
-In [next part](writing-a-plug-in/3),
+In [next part](../3),
we will see how to process the image tile by tile. We will also
have a look at preferences, by modifying our algorithm so it can
take an input parameter.
+[](http://creativecommons.org/licenses/by-nc-sa/2.5/)
-<para role="images">
-<ulink url="http://creativecommons.org/licenses/by-nc-sa/2.5/";>
-<mediaobject>
-<imageobject>
-<imagedata fileref="http://creativecommons.org/images/public/somerights20.gif"/>
-</imageobject>
-<textobject>
-<phrase>Creative Commons License</phrase>
-</textobject>
-</mediaobject>
-</ulink>
-
-This work is licensed under a <ulink
-url="http://creativecommons.org/licenses/by-nc-sa/2.5/";>Creative
-Commons Attribution-NonCommercial-ShareAlike 2.5
-License</ulink>.
-
-
+This work is licensed under a [Creative Commons
+Attribution-NonCommercial-ShareAlike 2.5
+License](http://creativecommons.org/licenses/by-nc-sa/2.5/).
diff --git a/content/resource/writing-a-plug-in/3.md b/content/resource/writing-a-plug-in/3.md
index ca1e527..58b797a 100644
--- a/content/resource/writing-a-plug-in/3.md
+++ b/content/resource/writing-a-plug-in/3.md
@@ -45,7 +45,7 @@ sent when one needs it and freed when one asks for another one.
Nevertheless, we can tell our plug-in to keep a tile cache to
avoid this constant round trip, by calling the function:
-```
+```C
gimp_tile_cache_ntiles (gulong ntiles);
```
@@ -58,7 +58,7 @@ divided by the tile width, plus one. So, for a layer width of
tiles, we can double that number to compute the ideal cache size
for our plug-in.
-```
+```C
gimp_tile_cache_ntiles (2 * (drawable->width /
gimp_tile_width () + 1));
```
@@ -95,7 +95,7 @@ The modified code to get this behaviour is below. Most of the
work is done in the process_row function. init_mem and shuffle
are there to keep the blur code clean and small.
-```
+```C
static void blur (GimpDrawable *drawable);
static void init_mem (guchar ***row,
@@ -299,7 +299,7 @@ First we create a structure to allow saving and returning
options. Usually one does this even for plug-ins with only one
parameter.
-```
+```C
typedef struct
{
gint radius;
@@ -323,7 +323,7 @@ Finally, in interactive mode, we add a few lines that will build
the graphical interface allowing options modification.
-```
+```C
static void
run (const gchar *name,
gint nparams,
@@ -418,7 +418,7 @@ GNOME Human Interface Guidelines. GimpPreview also appeared in
blur_dialog1.png
Blur dialog
-```
+```C
static gboolean
blur_dialog (GimpDrawable *drawable)
{
@@ -529,7 +529,7 @@ into account.
Here are the two functions in their last version:
-```
+```C
static void
blur (GimpDrawable *drawable,
GimpPreview *preview)
@@ -737,12 +737,9 @@ widgets to make a nice user interface.
Thanks to my wife Anne and to David Odin (preview master) for
helping me while I was writing this article.
-<ulink url="http://creativecommons.org/licenses/by-nc-sa/2.5/";>
-<imagedata fileref="http://creativecommons.org/images/public/somerights20.gif"/>
-<phrase>Creative Commons License</phrase>
-
-This work is licensed under a <ulink
-url="http://creativecommons.org/licenses/by-nc-sa/2.5/";>Creative
-Commons Attribution-NonCommercial-ShareAlike 2.5
-License</ulink>.
+[](http://creativecommons.org/licenses/by-nc-sa/2.5/)
+This work is licensed under a [Creative Commons
+Attribution-NonCommercial-ShareAlike 2.5
+License](http://creativecommons.org/licenses/by-nc-sa/2.5/).
diff --git a/content/resource/writing-a-plug-in/_index.md b/content/resource/writing-a-plug-in/_index.md
index 7c47501..db17b3f 100644
--- a/content/resource/writing-a-plug-in/_index.md
+++ b/content/resource/writing-a-plug-in/_index.md
@@ -8,7 +8,7 @@ show_subs = false
ℹ️ *The various documents listed below may not be very up-to-date. In particular,
you will not find documentation for the upcoming v3.0 API and plug-in creation
-tutorials. We are currently in the process of rebuilding proper plug-in
+tutorials yet. We are currently in the process of rebuilding proper plug-in
developer documentation. With a bit of patience, this will soon contain
up-to-date information.* ⏳
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
![http://creativecommons.org/images/public/somerights20.gif"/](http://creativecommons.org/images/public/somerights20.gif"/){kind=link}
