Commit Graph

43 Commits

Author SHA1 Message Date
Jehan 2a00a9e60a Issue #434: remove broken plural support for GimpUnit.
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!
2024-08-06 11:39:57 +02:00
Alx Sa 2e6938b3da app: Rename app/core GimpVectors vectors API...
...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.
2024-07-13 05:07:57 +00:00
Alx Sa e8df68fb65 libgimp, app, pdb: Rename GimpVectors to GimpPath
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.
2024-07-12 06:16:25 +00:00
Jehan 4a30f431fd app: work with a GimpPalette rather than a colormap.
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.
2024-02-11 23:28:03 +01:00
Jehan f6dd7f9b3a app: get rid of return_if_no_drawable() macro and…
… gimp_image_get_active_drawable() function!

Also fixing some memory leaks from previous usages of the multi version
return_if_no_drawables().
2022-11-09 01:24:34 +01:00
Jehan 81b569cb8c Issue #8124: plug-in localization now totally moved plug-in side.
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.
2022-07-05 12:22:32 +02:00
Jehan 95abf39066 app, libgimp: reverse internal l10n logic of plug-in labels in core app.
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.
2022-06-05 01:57:02 +02:00
Niels De Graef 8eb7f6df9e Remove GimpStringArray in favor of GStrv
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
2022-02-12 00:07:53 +00:00
Jehan 362fae9147 app, devel-docs: saving the item sets in XCF (bumping to XCF 16).
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.
2021-12-23 13:45:20 +01:00
Jehan 084906dbf1 app, devel-docs, libgimp, pdb: remove gimp_item_set_linked().
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.
2021-12-23 13:45:20 +01:00
Jehan 2ce84b5245 app, devel-docs, libgimp, pdb: delete gimpitem-linked.[ch].
Getting rid of the last usage from these files dedicated to outdated
item link concept.
2021-12-23 13:45:20 +01:00
Jehan 26615fde92 app, devel-docs, libgimp, pdb: now removing gimp_item_linked_rotate(). 2021-12-23 13:45:20 +01:00
Jehan 6f901dfe3e app, devel-docs, libgimp, pdb: get rid of gimp_item_linked_translate().
Similarly to the previous commit, we get rid of "item link" code for
translating items.
2021-12-23 13:45:20 +01:00
Jehan 26d696ce9d app, devel-docs, libgimp, pdb: remove item link ref in flip code.
"Item links" concept is no more in the GUI so we are progressively
removing reference and implementation of this in the core code.
2021-12-23 13:45:20 +01:00
Niels De Graef 878804fb01 Cleanup GObject signal marshallers
* 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.
2020-04-01 21:20:01 +00:00
Ell fc17f0ed0c app: streamline GimpHistogram; avoid spurious channel switch in histogram view
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.
2019-10-22 15:50:13 +03:00
Jehan 5d2dbfe2e8 app: gdk_threads_(enter|leave)() deprecated since GDK 3.6.
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.
2019-07-22 11:25:24 +02:00
Ell ed7ea51fb7 app: remove "Edit -> Fade..."
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.
2018-12-27 11:44:25 -05:00
Ell 3f04e349cf app: Add gimp_channel_flood() function
This function applies the "gimp:flood" operation to the channel.
2016-01-25 22:58:28 +01:00
Martin Nordholts 9f1187f6a5 app: Prefix TileManager functions
read_pixel_data() -> tile_manager_read_pixel_data()
write_pixel_data() -> tile_manager_write_pixel_data()
read_pixel_data_1() -> tile_manager_read_pixel_data_1()
write_pixel_data_1() -> tile_manager_write_pixel_data_1()

for consistency.
2011-09-07 12:08:43 +02:00
Martin Nordholts ac773489e4 app: gimp_image_get_uri() -> gimp_image_get_uri_or_untitled() 2011-01-26 07:55:14 +01:00
Martin Nordholts cc7755f876 Port stuff to gimp_item_is_text_layer()
Port stuff to gimp_item_is_text_layer() instead of
gimp_drawable_is_text_layer(). Nevermind the previous commit, it
should never have been pushed...
2010-10-05 07:39:00 +02:00
Hans Breuer d94419a9fd updated include <string.h> for memcmp() include <string.h> for strcmp()
2008-10-03  Hans Breuer  <hans@breuer.org>

	* **/makefie.msc gimpdefs.msc app/gimpcore.def : updated
	* app/core/gimpcurve.c : include <string.h> for memcmp()
	* app/gegl/gimpcurvesconfig.c : include <string.h> for strcmp()

svn path=/trunk/; revision=27118
2008-10-03 19:27:54 +00:00
Hans Breuer 9a1d5f3453 **/makefile.msc app/gimpcore.def : updated so it compiles and links
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
2008-01-04 18:42:07 +00:00
Hans Breuer 4c7289a54b an ugly but working variant for no varargs macros
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
2007-12-09 14:19:02 +00:00
Hans Breuer c17fbf8c14 updated msvc build add ENABLE_TOOLBOX_MENU, it should only vanish on Mac
2007-10-27  Hans Breuer  <hans@breuer.org>

	* app/base/makefile.msc app/file/makefile.msc app/gimpcore.def
	  app/gui/makefile.msc app/plug-in/makefile.msc
	  libgimpwidgets/makefile.msc : updated msvc build
	* config.h.win32 : add ENABLE_TOOLBOX_MENU, it should only
	vanish on Mac OSX (Quartz build)


svn path=/trunk/; revision=23964
2007-10-27 12:41:43 +00:00
Hans Breuer 024ef60a49 updated msvc build
2007-08-05  Hans Breuer  <hans@breuer.org>

	* **/makefile.msc app/gimpcore.def : updated msvc build


svn path=/trunk/; revision=23118
2007-08-05 15:16:02 +00:00
Hans Breuer f8b13080e4 updated
2007-03-04  Hans Breuer  <hans@breuer.org>

	* **/makefile.msc app/gimpcore.def : updated


svn path=/trunk/; revision=22041
2007-03-04 19:04:42 +00:00
Hans Breuer f8d14112c4 updated #include "file/file-utils.h" for file_utils_uri_display_name
2007-01-13  Hans Breuer  <hans@breuer.org>

	* **/makefile.msc app/gimpcore.def : updated
	* app/display/gimpdisplay-handlers.c : #include "file/file-utils.h"
	for file_utils_uri_display_name
	* plug-ins/imagemap/imap_statusbar.c : g_snprintf instead of snprintf


svn path=/trunk/; revision=21705
2007-01-13 22:41:21 +00:00
Hans Breuer 3551bbcca0 updated
2006-10-27  Hans Breuer  <hans@breuer.org>

	* **/makefile.msc app/gimpcore.def : updated
2006-10-27 16:04:53 +00:00
Hans Breuer ccb25e3798 updated
2006-09-08  Hans Breuer  <hans@breuer.org>

	* **/makefile.msc app/gimpcore.def : updated

	* app/paint/gimpperspectiveclone.c : error C2057: expected constant
	expression. Stack allocation of dynamic sized arrays is afaik a GCC
	extension, use g_alloca() instead.
2006-09-08 11:45:06 +00:00
Hans Breuer ad6829dde0 include "gimpcontext.h" for gimp_context_set_gradient()
2006-09-03  Hans Breuer  <hans@breuer.org>

	* app/core/gimp-gradients.c : include "gimpcontext.h" for
	gimp_context_set_gradient()

	* **/makefile.msc app/gimpcore.def : updated
2006-09-03 12:39:24 +00:00
Hans Breuer 37e4b80204 updated
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-08-15 15:13:08 +00:00
Hans Breuer 429d71e5e2 updated dont include "config/gimpbaseconfig.c", it gives an redefinition
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)
2006-05-13 17:05:15 +00:00
Hans Breuer 50b0105822 updated
2005-06-26  Hans Breuer  <hans@breuer.org>

	* **/makefile.msc app/gimpcore.def : updated
2006-02-26 19:00:33 +00:00
Hans Breuer 0b515bec9b updated
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-09-25 19:30:55 +00:00
Hans Breuer d9ac028c50 updated dont include "gimpmessagedialog.c" to avoid redefinitions. Instead
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-07-10 16:24:57 +00:00
Hans Breuer 28a2b13581 build menus with nmake, too menus/Makefile.am : added to EXTRA_DIST
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-04-24 15:39:15 +00:00
Hans Breuer c6f63ea4e1 TILE_WIDTH is used unconditionally so always include "tile.h" WIN32 needs
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
2005-02-19 00:50:36 +00:00
Hans Breuer 696663a611 [new file] app/dialogs/Makefile.am : added to EXTRA_DIST
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-11-21 14:22:45 +00:00
Hans Breuer eafd79de87 gimp_create_display() with the right parameters order
2004-08-09  Hans Breuer  <hans@breuer.org>

	* app/core/gimp-edit.c(gimp_edit_paste_as_new) :
	gimp_create_display() with the right parameters order

	* app/widgets/gimpwidgets-utils.c (gimp_message_box_set_icons)
	handle gtk_style_lookup_icon_set() returnig NULL

	* app/gimpcore.def app/widgets/makefile.msc
	  themes/default/images/makefile.msc : updated
2004-08-08 22:47:23 +00:00
Hans Breuer 44f617d85b [commited mostly yesterday, but ChangeLog was missing]
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-08-02 18:34:01 +00:00
Hans Breuer 3b3039148c build but *dont link* display-enums.obj, widget-enums.obj and
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
2004-08-01 20:51:12 +00:00