no matter how editing was started (double click, keyboard activate, F2).
Connect to "editing-started" of the name cell and set the object's
real name directly on the GtkCellEditable, instead of trying to hack
around in the tree store before the actual editing starts.
so all the view renderers already have the right context when the
parent interface code selects the right item, which in turn requires
the context to be already set on the renderers. Fixes warnings when
dragging dockables around.
Really find a *widget* in gimp_dialog_factory_find_widget(), don't
just return the first found session info's widget. It's perfectly fine
for a session info to have a NULL widget, if that dialog is not
currently open.
- move the code that sets the tool options' "defined" and "serialize"
properties from GimpToolInto to GimpToolOptions so they are always
set correctly.
- make GimpToolOptions fix broken serialized NULL tools automatically.
- make sure a GimpToolPreset's tool options always has a tool set. If all
fails, set a NULL tool explicitly and let the logic in GimpToolOptions
find the right tool.
- set GimpToolPreset's "use" booleans to FALSE for context properties
that have no effect on the tool.
- set GimpToolPresetEditor's toggle insensitive for these properties.
Because it's generally the right thing to do, and server grabs broke
badly with input devices / client side windows.
gimpdisplayshell-grab.c: change logic to only server-grab if an event
is passed to the pointer grab/ungrab functions, but always use
gtk_grab_add/remove() which is sufficient in most cases.
gimpdisplayshell-tool-events.c: have the grab functions grab the
server only for space-bar scrolling and do all tool interaction,
including ruler clicks, with gtk_grab_add/remove(). Refactor things
a bit to also use the grab API for button-2 scrolling.
gimpdeviceinfo-coords.c: transform the event's coords to the canvas'
coordinate system, they might come from a ruler now.
This fixes the following bugs:
Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed...
Bug 644351 - Gimp misses some strokes especially when drawing fast
Bug 645747 - Gimp is now unusable on xfce4
Dragging a channel preview (not RGBA) over a layer preview
GIMP used to print:
Gimp-Core-CRITICAL **: gimp_container_get_child_index: ...
assertion `GIMP_IS_CONTAINER (container)' failed
but don't fix it for item trees yet (refactoring only). Kill the
"exclusive liked" function which only existed because it was so easy
to have, but was always utterly useless. Prove me wrong and I will
revive it.
Add new utility function gimp_get_all_modifiers_mask() which returns
all modifiers used for "useful" things on the current platform, like
in the commit below.
and remove them from the various public construct() functions. Had to
change construction in GimpDataFactoryView slightly because of GObject
construct property constraints.
by checking for gimp_get_toggle_behavior_mask() instead of
GDK_CONTROL_MASK. This is a total hack but happens to simply
do the right thing on all platforms.
and remove it from all other places. We only want to have the virtual
modifiers when displaying a modifier string (and in some other cases,
but these are all handled internally by GTK+).
- gimp_modifiers_to_channel_op() translates a modifier state to REPLACE,
ADD, SUBTRACT or INTERSECT.
- gimp_replace_virtual_modifiers() uses gdk_keymap_add_virtual_modifiers()
to replace the physical bits in a modifier state to their virtual
counterparts (and not just adds the virtual ones like the GDK
function).
Introduced two virtual functions to a GimpViewable
'set_expanded' and 'get_expanded'
and a PROP_GROUP_ITEM_FLAGS to load/save the expanded state
of layer_groups and use them.
Add an explicit search entry, so the treeview's automatic search
popup doesn't break our grab and closes the dialog in the middle
of setting up the serach popup.
instead of checking for event->button == 3, so context menus
work correctly on the Mac. Didn't change the image menu yet
because thet requires some more refactoring.
which is look at the right modifier when checking if a key event
can invoke an accelerator. Also get the mnemonic modifier from
GTK instead of hardcoding it, and don't check for it if mnemonics
are disabled, which is the right thing to do on all platforms.
Apparently wilber_get_extents is called the first time
with a cairo_t with device_offset different than the other
times, since the path is copied the first time, afterwards
it appears offset.
Make GimpToolbox and GimpToolPalette use the GimpUIManager and
GimpDialogFactory of the top container instead of holding references
on their own. If they hold references on their own, we need to update
these when we move e.g. GimpToolbox between different top level
containers such as GimpDockWindow and GimpImageWindow. Failure to do
this cased problems talked about in bug 646794 (case 2).
This is a quick fix because the call can block and needs to be ported
to the async API. I simply disabled the entire block that gets the
icon from GIO.
In single-window mode, gimp_session_managed_set_aux_info() will set
the size of the dock areas at the sides. If we don't wait for those
areas to get their size-allocation, we can't properly restore the
docks inside them, so do that in an idle callback.
Also add a required call to gimp_test_run_mainloop_until_idle()
because of this in the 'automatic_tab_style' test.
Rememeber if image windows are opened because we want the
gimp_session_info_restore() code to run for the single-image window
once that code is in place.
When we get to gimp_dialog_factory_dialog_configure() and do
gimp_session_info_read_geometry(), the window geometry has not yet
been updated, i.e. gimp_session_info_read_geometry() gives the session
info the size of the *previous* configure event.
Solve this by giving gimp_session_info_read_geometry() the configure
event so it can use that size when availble.
If we don't do this change, then we get bogus values of the size of
image window when repeatedly switching between single- and
multi-window mode.
In gimp_session_info_restore() there is code to create a dialog from a
session info. GimpSessionInfo lives in the widgets module. Thus we
can't add restoration code that depends on a higher level module. In
particular, we can't add code to restore docks in an GimpImageWindow
since GimpImageWindow lives in the display module. And we need such
code to be able to restore a single-window mode session.
Since dialogs are defined in the dialogs module, it makes sense to
also have the code that restores a dialog in that module.
So, add a 'restore_func' member to GimpRestoreDialogFunc of type
GimpRestoreDialogFunc and move the code there.
Add GimpDockContainer::get_dock_side() and write that info in the
sessionrc file. In single-window mode, a dock can be either on the
left or right side of the image window. In a dock window however, the
side concept doesn't apply ('side' has nothing to do with what column
a dock is in in a GimpDockColumns)
Add image_window boolean to GimpDialogFactoryEntry and rename
FOREIGN_NOT_HIDEABLE() to IMAGE_WINDOW(). We need to treat image
windows a bit special when we restore a single-window mode session.
Make GimpDockContainer::get_docks() return a new list and not just a
pointer to a list so that GimpImageWindow can implement it (who needs
to merge its two GimpDockColumns lists).
Don't set the first page of the restored dockbook active if there are
less than two pages. Also add a comment that explains why we return
the dockbook even though we know that all its dockables failed to
restore.
Make GimpDockWindow implement the GimpDockContainer interface. The
plan is to make GimpImageWindow also implement the GimpDockContainer
interface when we start to session manage docks in single-window mode.
We now have to classes that contain docks, GimpDockWindow and
GimpImageWindow (in single-window mode). Introduce a GimpDockContainer
interface so we can cope with these in an abstract way.
Rename GimpSessionInfoDock::identifier to dock_type, because it isn't
really an identifier; there might be several instance with dock_type
being "gimp-dock". This is a preparation for adding an actual
'identifier' member.
which allows to restrict the scale to a range that is smaller than
that of the model GtkAdjustment. This way we can enter large values in
the entry or by dragging beyond the end of the scale, but keep a
reasonably usable scale range for "normal" values.
Michael Natterer