Matthias Clasen [Thu, 2 Aug 2012 23:49:15 +0000 (01:49 +0200)]
docs: Improve man page generation
Use $(AM_V_GEN) for generating man pages, and set some parameters
for the XSL stylesheets. Among other things, don't generate AUTHORS
and COPYRIGHT sections.
Matthias Clasen [Wed, 1 Aug 2012 08:26:17 +0000 (10:26 +0200)]
Expand the thread deprecation documentation
The story is slightly different for applications vs libraries;
make it clear that libraries should continue using the lock so
we don't break applications that haven't been ported to the
'single thread' model yet.
notebook: restore previous behaviour wrt. unparenting of tab labels
When the tab label gets removed from the notebook on widget
desctruction, we should still unconditionally unparent it from the
notebook, since failing to do so will keep a stray reference alive.
In case applications rely on the tab label being destroyed to release
other references (e.g. because the tab label is a custom object, or
another object's lifecycle is tied to it using g_object_set_data_full()),
this will also possibly cause other references to get leaked.
In Nautilus, the result was we were failing to release the reference to
a NautilusWindowSlot, and other parts of the application relied
on it being destroyed at a specific time instead, causing the
application to crash when closing a window.
menubutton: Clear references in dispose, not finalize
We need to do this here so that an explicit gtk_widget_destroy
on either the widget or a container that holds it will kill the
reference to the menu or model.
This commit deprecates gdk_threads_init, gdk_threads_enter,
gdk_threads_leave and gdk_threads_set_lock_functions. Using GTK+
from multiple threads does not work at all on Windows, and is
problematic on other platforms as well. We want to move to a world
where all GTK+ calls are made from the main thread.
Use g_main_context_invoke, g_idle_add and related functions if you
need to schedule GTK+ calls from other threads.
modules: Don't use GDK_THREADS_ENTER/LEAVE macros internally
These are just wrappers for the functions, and we want to
deprecate them. Stopping to use them internally is a good
first step. Also define GTK_COMPILATION so we can keep using
gdk_threads_enter/leave without causing deprecation warnings.
Chun-wei Fan [Thu, 26 Jul 2012 07:39:51 +0000 (15:39 +0800)]
Visual C++ projects: Update .dll/.lib naming
Remove the "-win32-" from the output file names for the GDK and GTK+ DLLs,
like what is now done for quite a while on other platforms
(and MinGW builds), for consistency reasons. This is due to GDK/GTK+
are buildable with multiple backends.
Note: For references, the Windows build only builds the Win32 backend
for the time being.
Rob Bradford [Wed, 18 Jul 2012 15:16:56 +0000 (16:16 +0100)]
wayland: Fallback to setting transient windows if no seat available
If we don't have a wl_seat - because a grab hasn't been initialised by GTK+
then fallback to making the shell surface transient to the parent rather than
a popup surface.
wayland: don't wipe clipboard on any change coming from the same owner.
We now support independent selection and primary clipboards, and avoid
wiping clipboard on modifying its contents from the same owner. This fixes
most of the interaction issues with clipboard and selection.
GtkTreeModelFilter: Fix _iter_previous() when iter points at 2nd node
GSequence iterators point at the position between two elements so an
iterator pointing at the N tree model node is actually between the N-1
and N sequence elements. This means that asking for the previous
sequence iterator first and then checking if it is the begin iterator
would yeld true for an iterator pointing at the 2nd tree model node
and make us return FALSE mistakenly.
wayland: Initial version of keyboard key event handling
Review comment: I think the implementation of the vfuncs in gdkkeys-wayland.c
depend on that we're using the keysysm as the hardware keycode. I think that
needs to be evaluated for the future. But for now this patch gives reasonably
complete keyboard input.
wayland: Refactor the keymap handling so it is associated with device
Although GDK expects the keymap to be associated with the display under
Wayland this is really associated with the input device so expose this by
finding the first keyboard device.
The code that was trying to limit preview size changes was
running into some width-for-height pitfalls. It turns out
that the dialog behaves quite ok without this code, so just
remove it.
Clear cached row sensitivity when the filter changes
Now that filters may affect sensitivity of rows, we need
to clear the sensitivity column from the cache when the
filter changes. This fixes the problem where selecting a
different filter does not update the sensitivity of folders
until you change directories.
Make computing and setting the visibility/filters atomic operations
This way we remove paired function calls (compute/set pairs), and also make
it possible to avoid computing a filter twice, as setting the visibility
depends on filteredness.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Make it clear that 'filtered' means 'filtered_out'
It bothers me that we call gtk_file_filter_filter(), then negate the result,
and the return *that* from node_should_be_filtered(). So, rename 'filtered'
throughout GtkFileSystemModel to 'filtered_out' to mean things that didn't
pass the filter.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This was a copy-paste leftover from node_set_visible(). Filters are not
concerned with model freezes, so node_set_filtered() does not
need to handle freezes, either.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Carlos Garnacho [Fri, 13 Jul 2012 13:03:30 +0000 (15:03 +0200)]
menu: Fix touch scrolling on menus close to the monitor edge
Specially in the case of comboboxes, those menus could enable scrolling
even if the contents could fit in the work area, and could show blank
space in order to line up the selected item with the combobox.
When such thing happens, take into account scroll_offset when relocating
the menu contents so contents don't jump directly onscreen, and apply
it so scrolling is allowed in the direction that brings the menu onscreen
and blocked in the opposite direction.
Also, wait for cancelling the scroll operation until the touch is released
even if the scrolling arrows disappeared, so the menu item underneath isn't
selected right away.
Carlos Garnacho [Fri, 13 Jul 2012 13:55:44 +0000 (15:55 +0200)]
Ensure pixbufs as entry icons get resized
Entries don't expand vertically if they are given pixbufs larger
than the calculated height for the current font, resulting in
cropped icons, so force the pixbuf to be rescaled so it fits
on the entry allocated size.
Carlos Garnacho [Wed, 6 Jun 2012 16:16:05 +0000 (18:16 +0200)]
icontheme: Don't assume a symbolic icon size of 16x16
If the symbolic icon has other size than 16x16, the embedder
SVG that overrides colors would still force that size, resulting
in clipping instead of resizing. So fetch the original pixbuf
size the first time a symbolic icon is requested for a GtkIconInfo,
and use that size for the embedder SVG so it can be scaled properly
afterwards.
projects / ~andy / gtk / log