...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
I'm sure some plug-ins need to add their items *not* at the toplevel,
but since making plug-ins really tree-aware is a lot more work than
just fixing insert positions, I went for passing -1 as parent in
almost all cases. And because of laziness...
Finally commit the patch from Luidnel Maignan, but don't spit messages
when the effected region is empty (core functions don't spit messages
either). Also got rid of some x2 and y2 variables that are not needed
any longer.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2008-02-22 Sven Neumann <sven@gimp.org>
* plug-ins/common/tileit.c
* plug-ins/common/warp.c
* plug-ins/common/struc.c: fixed the same problem as in the Wind
plug-in here as well (see bug #516369).
svn path=/trunk/; revision=24944
2007-11-09 Michael Natterer <mitch@gimp.org>
* libgimpwidgets/gimphelpui.[ch]: use the new tooltip API instead
of the old deprecated one. Removed _gimp_help_init(). Remember
whether tooltips are enabled or not in a local variable that can
only be altered at startup time and not after. The API now expects
markup instead of plain text which might cause warnings and
perhaps needs to be changed.
* libgimpwidgets/gimpwidgets-private.c: don't call _gimp_help_init().
* app/config/gimpguiconfig.c: made show-tooltips a
GIMP_CONFIG_PARAM_RESTART property.
* app/widgets/gimptoolbox-color-area.c: don't add the tooltip here...
* app/widgets/gimptoolbox.c: ...but here (as for all other
indicators). Also escape '&' properly because we now use markup.
* app/tools/gimpselectionoptions.c
* app/widgets/gimpeditor.c
* app/widgets/gimpwidgets-utils.c: print modifiers and
shortcuts in bold instead of in ().
* app/widgets/gimpcontainertreeview.c: show tooltips on rows if
gimp_viewable_get_description() returns a tip.
* app/dialogs/preferences-dialog.c
* plug-ins/jpeg/jpeg-save.c
* plug-ins/MapObject/mapobject_ui.c
* plug-ins/Lighting/lighting_ui.c
* plug-ins/common/animationplay.c
* plug-ins/common/warp.c: no need to add event boxes just to have
tooltips, the new ones work on all widgets.
svn path=/trunk/; revision=24093
2006-08-08 Sven Neumann <sven@gimp.org>
* plug-ins/common/warp.c (diff_prepare_row): applied patch from
Robert Ögren to fix a segfault on 64bit architectures (bug
#327479).
2005-09-30 Michael Natterer <mitch@gimp.org>
* plug-ins/*/*.c: removed '...' from progress messages. They are
redundant because we are already in a progress. Ported some more
g_strdup_printf()/gimp_progress_init() to
gimp_progress_init_printf(). Core will follow...
2005-09-09 Michael Natterer <mitch@gimp.org>
Added parent window API to the GimpProgress interface and to
the libgimp progress stuff. Might look strange, but does
the right thing in almost all cases (image window, file dialog,
script-fu dialog etc). Fixes bug #62988.
* app/core/gimpprogress.[ch]: added GimpProgress::get_window()
which should return a toplevel window ID if the progress is in a
window that wants to be the transient parent of plug-in dialogs.
* app/widgets/gimpwidgets-utils.[ch] (gimp_window_get_native): new
function which returns the window handle of a GtkWindow's GdkWindow.
* app/widgets/gimpfiledialog.c: implement ::get_window().
* app/display/gimpdisplay.[ch]: ditto. Removed window handle API.
* app/gui/gui-vtable.c: changed accordingly.
* libgimpbase/gimpbaseenums.[ch] (enum GimpProgressCommand):
added GIMP_PROGRESS_COMMAND_GET_WINDOW.
* app/plug-in/plug-in-progress.[ch] (plug_in_progress_get_window):
new function. Also renamed some functions to match the
GimpProgress interface, and not the legacy PDB procedure names.
* tools/pdbgen/pdb/progress.pdb
* app/core/gimppdbprogress.c: implement get_window() on both
sides of the wire, keeping backward compatibility (hopefully).
* libgimp/gimpprogress.[ch]: deprecated gimp_progress_install()
and added gimp_progress_install_vtable() which takes a vtable with
padding to be extensible. Added get_window() vtable entry and
dispatch it accordingly. Also added pulse() which was implemented
in a hackish way before. Everything is of course backward
compatible.
* libgimp/gimpprogressbar.c: inmplement the get_window() stuff
so a plug-in dialog containing a progress can be the transient
parent of another dialog in another plug-in.
* libgimp/gimpui.[ch] (gimp_ui_get_progress_window): new function
which returns a foreign GdkWindow of this plug-ins progress
window.
Renamed gimp_window_set_transient_for_default_display() to
gimp_window_set_transient() and make it use the progress' window
handle instead of the display's (which is the right thing to do in
almost all cases).
* libgimp/gimp.def
* libgimp/gimpui.def: add the new functions.
* tools/pdbgen/enums.pl
* app/pdb/internal_procs.c
* app/pdb/progress_cmds.c
* libgimp/gimpprogress_pdb.[ch]: regenerated.
* libgimp/gimpexport.c
* plug-ins/*/*.c: follow API change.
2005-09-05 Sven Neumann <sven@gimp.org>
* plug-ins: Call gimp_window_set_transient_for_default_display()
for most plug-in dialogs. Not yet done are load and save dialogs
and dialogs created from language bindings.
