Rather than trying to implement full i18n plural support, we just remove
this failed attempt from the past. The fact is that to get proper
support, we'd basically need to reimplement a Gettext-like plural
definition syntax within our API, then ask people to write down this
plural definition for their language, then to write every plural form…
all this for custom units which only them will ever see!
Moreover code investigation shows that the singular form was simply
never used, and the plural form was always used (whatever the actual
unit value displayed).
As for the "identifier", this was a text which was never shown anywhere
(except in the unit editor) and for all built-in units, as well as
default unitrc units, it was equivalent to the English plural value.
So we now just have a unique name which is the "long label" to be used
everywhere in the GUI, and abbreviation will be basically the "short
label". That's it. No useless (or worse, not actually usable because it
was not generic internationalization) values anymore!
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
This commit renames the GimpVectors
object to GimpPath in both app/core and
in libgimp. It also renames the files
to gimppath.[ch] and updates the relevant
build and translation files.
There are still outstanding gimp_vectors_* ()
functions on the app side that need to be renamed
in a subsequent commit.
We historically have both the colormap and palette concept in core GIMP,
though they are actually kinda the same concept, except that with
"colormap" we work with an array of raw data and it's a lot less
color-aware. It is still much more efficient in some specific cases,
such as when converting the image (we can then convert the whole palette
as a single buffer, because the image palette is space-restricted
anyway), when storing undo data or when storing/loading in XCF.
But for all the rest, let's use gimp_image_get_colormap_palette() and
work with the GimpPalette API.
Plug-in localization was always partially plug-in side, especially for
things like custom GUI. But labels or blurb in GIMP (such as in menus or
action search) were localizing GIMP side.
It had many drawbacks:
- To get menu localization, a plug-in had to set up gettext, even though
they might want to use something else for their GUI (after all, giving
facilities for gettext is a good idea, but there is no reason to force
using this system).
- There was a complex internal system passing the localization domain
name, as well as the catalog file system path to core, then through
various classes which we can now get rid of.
- There could be domain name clashes, if 2 plug-ins were to use the same
i18n domain name. This was handled in now removed functions
gimp_plug_in_manager_get_locale_domains() by simply keeping a unique
one (and gimp_plug_in_manager_bind_text_domains() would just bind the
domain to the kept directory). In other words, one of the duplicate
plug-ins would use the wrong catalog. We could try to make the whole
thing more complicated or try to forbid plug-ins to use any random
name (in particular made easier with the new extension wrapper). But
anyway this whole issue doesn't happen anymore if localization is
fully made plug-in side, so why bother?
I tried to evaluate the advantages of the core-side localization of
plug-in labels/blurbs and could only find one theoretical: if we wanted
to keep access to the original English text. This could be useful
(theoretically) if we wanted to search (e.g. in the action search) in
both localized and English text; or if we wanted to be able to swap
easily en/l10n text in a UI without reload. But even if we were to ever
do this, it would only be possible for plug-ins (GEGL operations in
particular are localized GEGL-side), so it lacks consistency. And it's
unsure why special-casing English should really make sense for other
language natives who want text in their lang, and search in their lang.
They don't necessarily care about original.
So in the end, I decided to simplify the whole thing, make localization
of plug-ins a plug-in side thing. Core will only receive translated text
and that's it. It cuts a lot of code out of the core, simplify runtime
processing and make plug-in creation simpler to understand.
The only think I still want to look at is how exactly menu paths are
translated right now. Note that it still works, but it's possible that
some things may be worth improving/simplifying on this side too.
I hesitated a lot whether we should just drop the whole localization of
plug-ins' label and description (blurb) within the core. Actually the
commit messages I wrote a few days ago were moving towards this logic.
It really looks to me like plug-in localization can happen fully within
plug-in themselves. As far as I can see, the only advantage which the
current logic has theoretically is that if we needed, we have access to
both the original strings and their translations (e.g. it could be
useful for text search). Nevertheless I am not sure if we will ever make
use of this, and this is limited cases as all filters turned GEGL ops
don't have such ability anyway.
Nevertheless since previous contributors clearly put quite a lot of work
on this code of localizing the plug-in's label and description within
the main binary, I want to give myself a little more time to think and
study the whole thing because doing anything rash.
In the meantime, what changes is that by default now, a plug-in without
a local gettext catalog is simply not localized. In particular, the core
process doesn't try to localize it using the default catalog, a.k.a.
GETTEXT_PACKAGE"-std-plug-ins" ("gimp30-std-plug-ins"). It just doesn't
make sense and the worst which could happen would be to get unexpected
and wrong translations.
Now by default, plug-ins will try to find a catalog in their main
folder, named as this folder. If it fails to find it, a message is
printed to stderr and localization is disabled (rather than falling back
to a default catalog). It is up to plug-in developers to either install
a catalog, or implement set_i18n() to give the right catalog, folder, or
disable localization with gettext, as handled by libgimp.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
We now save and load layer and channel item sets. Only missing set types
are path ones, but the whole path item is just its own exception in the
XCF format, and adding support for it, while keeping compatibility with
older XCF seem like a small headache. I could do it, but I actually
wonder if it is worth it. Would people really need to store sets of
paths?
Also this commit finally gets rid of any remnant of the old item "link"
concept (I think), so we are getting close to merging the branch.
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
In GimpHistogram, get rid of the "n-channels" property and
corresponding gimp_histogram_n_channels() function. The former
returned the actual number of channels, but this wasn't too useful,
as channel values may not be sequential; the latter returned the
number of components. Instead, add an "n-components" property and
a corresponding gimp_histogram_n_components() function, both of
which return the number of components. Furthermore, add a
gimp_histogram_has_channel() function, which determines if the
histogram has a given channel; this allows for simple testing for
channel availability, which was done wrong in various places.
Adjust the GimpHistogram code for the changes, and clean it up,
fixing a few bugs.
Adjust users of GimpHisotgram for the changes. In particular,
in GimpHisotgramView, fix the channel-availability test when
setting the view's histogram (which happens whenever the active
drawable's preview is frozen), to avoid erroneously swithcing the
view's channel back to "Value" when a non-RGB channel is selected.
There are no replacements. Just we must make sure that all GTK+/GDK
calls are run from the main thread, which is already what we were doing.
Actually I don't even think these were doing anything as we were not
calling gdk_threads_init() so the default lock functions were not set
anyway. These were just bogus calls.
This commit completely removes the "Edit -> Fade..." feature,
because...
- The main reason is that "fade" requires us to keep two buffers,
instead of one, for each fadeable undo step, doubling (or worse,
since the extra buffer might have higher precision than the
drawable) the space consumed by these steps. This has notable
impact when editing large images. This overhead is incurred even
when not actually using "fade", and since it seems to be very
rarely used, this is too wasteful.
- "Fade" is broken in 2.10: when comitting a filter, we copy the
cached parts of the result into the apply buffer. However, the
result cache sits after the mode node, while the apply buffer
should contain the result of the filter *before* the mode node,
which can lead to wrong results in the general case.
- The same behavior can be trivially achieved "manually", by
duplicating the layer, editing the duplicate, and changing its
opacity/mode.
- If we really want this feature, now that most filters are GEGL
ops, it makes more sense to just add opacity/mode options to the
filter tool, instead of having this be a separate step.
2008-01-04 Hans Breuer <hans@breuer.org>
**/makefile.msc app/gimpcore.def : updated so it compiles and links
(almost, see bug #507298)
svn path=/trunk/; revision=24533
2007-12-09 Hans Breuer <hans@breuer.org>
* app/gimp-log.h : an ugly but working variant for no varargs macros
* app/base/base-utils.c(get_physical_memory_size) : fallback to
GetMemoryStatus() for older compiler/sdk
* app/core/gimplayer-floating-sel.c : second argument to g_set_error()
is an uint32, not a pointer
svn path=/trunk/; revision=24306
2006-08-15 Hans Breuer <hans@breuer.org>
* **/makefile.msc app/gimpcore.def : updated
* app/xcf/xcf-save.c(1464) : error C2036: 'void *' : unknown size
pointer arithmetics on void a pointer looks like a GCC extension
* app/tools/gimpbrightnesscontrasttool.c
app/tools/gimpcolorbalancetool.c
app/tools/gimphuesaturationtool.c
app/tools/gimpcolorizetool.c : #include "core/gimp.h" for gimp_message
* app/tools/gimpiscissorstool.c : use RINT() rather than rint()
* app/widgets/gimpcontrollerlist.c : #include "gimpwidgets-utils.h"
for gimp_show_message_dialog
* app/core/gimpprogress.c(229) : 'gimp_progress_message' must
return a value
2006-05-13 Hans Breuer <hans@breuer.org>
* **/makefile.msc app/gimpcore.def : updated
* app/core/gimp-util.c : dont include "config/gimpbaseconfig.c", it
gives an redefinition error with msvc. Instead include
config/gimpbaseconfig.h and libgimpconfig/gimpconfig-path.h
* plug-ins/common/psd_save.c : fix c99isms (declarations only at the
start of a block)
2005-09-24 Hans Breuer <hans@breuer.org>
* **makefile.msc : updated
* app/dialogs/user-install-dialog.c : only add the migrate page if
there is something to migrate from. Avoids on version being NULL.
* app/dialogs/file-save-dialog.c : the g_print() output was crashing
on the assumption that ->menu_label != NULL. It is for colorhtml.py.
* app/widgets/gimpselectiondata.c : use HAVE_UNISTD_H and move
* process.h definition by G_OS_WIN32 below it being defined
* app/widgets/gimpwidgets-utils.c(gimp_window_get_native) : cast
return value to (GdkNativeWindow) it is not necessary an int.
* libgimpwidgets/gimpwidgets.def : added gimp_zoom_type_get_type
* plug-ins/help/gimp-help-lookup.c : dynamic lookup of help_root
instead of hard-coding DATADIR/GIMP_HELP_PREFIX
* plug-ins/xjt/xjt.c : there is no pid_t with msvc, typedef one.
2005-07-10 Hans Breuer <hans@breuer.org>
* **/makefile.msc app/gimpcore.def : updated
* app/widgets/gimpcontrollerlist.c : dont include
"gimpmessagedialog.c" to avoid redefinitions.
Instead include gimpmessagebox.h and gimpmessagedialog.h
* plug-ins/common/raw.c : include <io.h>
* plug-ins/common/screenshot.c : make it compile. It
still has no code to actually work on win32.
2005-04-24 Hans Breuer <hans@breuer.org>
* menus/makefile.msc : build menus with nmake, too
menus/Makefile.am : added to EXTRA_DIST
* **/makefile.msc app/gimpcore.def : updated
* app/base/tmp-buf.c : there is no pid_t with msvc so typedef one
2005-02-19 Hans Breuer <hans@breuer.org>
* app/base/pixel-processor.c : TILE_WIDTH is used unconditionally
so always include "tile.h"
* app/base/tile-swap.c : WIN32 needs <process.h> for _getpid()
* app/dialogs/user-install-dialog.c : include gimpwin32-io.h
* libgimpbase/gimpwin32-io.h : there are no group or other
flags in msvcrt, define S_IGRP etc in terms of _S_IREAD etc
* plug-ins/script-fu/script-fu.c plug-ins/script-fu/siod-wrapper.c :
no script-fu server on win32, make respective function calls conditional
* libgimpconfig/makefile.msc : new file
* **/makefile.msc app/gimpcore.def : updated, gimp builds
and runs once more with ms toolchain
2004-09-21 Hans Breuer <hans@breuer.org>
* app/dialogs/makefile.msc : [new file]
app/dialogs/Makefile.am : added to EXTRA_DIST
* **/makefile.msc app/gimpcore.def : updated
* app/gimp.rc : let wilber be first
* app/widgets/gimppropwidgets.c : msvc6 can't cast uint64 either
* libgimpbase/gimpwin32-io.h : make up recent loss of ftruncate in GLib
* libgimpthumbnail/gimpthumbnail.c : <process.h> for getpid() on win32
* plug-ins/helpbrowser/dialog.c : include gimpwin32-io.h
* plug-ins/script-fu/siodwrapper.c plug-ins/script-fu/scrip-fu.c : there
is no script-fu-server on win32
2004-08-01 Hans Breuer <hans@breuer.org>
[commited mostly yesterday, but ChangeLog was missing]
* app/display/makefile.msc app/widgets/makefile.msc : build
but *dont link* display-enums.obj, widget-enums.obj and
gimpdisplayoptions.obj. They must be in the dll
* app/makefile.msc : build gimp.exe and gimp-console.exe both
using the same gimp-core.dll
* app/gimpcore.def : new file, exports for gimp-core.dll
* app/Makefile.am : added to EXTRA_DIST
* cursors/makefile.msc : new file to create gimp-tool-cursors.h
* cursors/Makefile.am : added to EXTRA_DIST
* **/makefile.msc : updated
* app/main.c app/app_procs.c : moved code to close the console
from the former to the later. It only is to be used if The Gimp
is not build as console app.
* plug-ins/gfig/gfig.c : dont gimp_drawable_detach() the same
drawable twice
* plug-ins/gfig-dialog.c() : added a g_return_if_fail() to avoid
crashing on File/Import
2004-07-31 Hans Breuer <hans@breuer.org>
* app/display/makefile.msc app/widgets/makefile.msc : build
but *dont link* display-enums.obj, widget-enums.obj and
gimpdisplayoptions.obj. They must be in the dll
* app/makefile.msc : build gimp.exe and gimp-console.exe both
using the same gimp-core.dll
* app/gimpcore.def : new file, exports for gimp-core.dll
* app/Makefile.am : added to EXTRA_DIST
* cursors/makefile.msc : new file to create gimp-tool-cursors.h
* cursors/Makefile.am : added to EXTRA_DIST
* **/makefile.msc : updated
* app/main.c app/app_procs.c : moved code to close the console
from the former to the later. It only is to be used if The Gimp
is not build as console app.
* plug-ins/gfig/gfig.c : dont gimp_drawable_detach() the same
drawable twice
* plug-ins/gfig-dialog.c() : added a g_return_if_fail() to avoid
crashing on File/Import
Jehan