Since ::drag-leave gets emitted before ::drag-drop, we can't just remove the drop feedback row
in drag-leave, as we *need* it during drag-drop. So, we use the same trick as in testdnd.c - we
install a timeout handler in our drag-leave callback, and remove the feedback in the timeout callback.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This lets us keep the new_bookmark_index untouched even when the drop state goes from armed to unarmed.
That will in turn let us drop in the right place...
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We used to divide the row in thirds vertically, and use the outer thirds for GTK_TREE_VIEW_DROP_BEFORE and AFTER, respectively.
Now we use *fourths*. This is so that we get equal areas for these:
GTK_TREE_VIEW_DROP_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_BEFORE
GTK_TREE_VIEW_DROP_INTO_OR_AFTER
GTK_TREE_VIEW_DROP_AFTER
This makes hovering tree rows much more positive.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This makes the feedback accurate and without hysteresis. Haven't I written this code ten times before?
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
For now it is the old, simple call to gtk_tree_view_set_drag_dest_row(). We'll do something
fancier in the following commits.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We want to show a little animation when a DnD operation is happening and the user hovers
between existing bookmarks. The animation should indicate the user that he's about to
create a new bookmark from the file right there.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This makes Wayland and X11 no longer call into XKB and libX11 for these
functions but use GDK's own copy of these functions, just like the
win32, quartz and broadway backends.
A function was doing nothing but calling a function that was in its own
source file doing nothing but calling a function in its own source file
that did nothing.
This is the new GtkPlacesSidebar widget, which is the sidebar used in
GtkFileChooser to display a list of places/folders that the user may
want to use. File managers are encouraged to use this widget for
their own global list of folders.
This is Tristan's *excellent* work, minus the old code for the shortcuts bar - that is all done
in GtkPlacesSidebar now.
The UI gets loaded from a Glade resource; most of the old code to create the UI by hand is gone.
There is still code for save_widgets_create(); this needs to be moved into the UI file, but it
is not a big deal.
gtk_file_chooser_default_init() calls a new post_process_ui() that takes care of all the things
that cannot be done directly in Glade.
Although GtkPlacesSidebar is a public widget, we can't have that in Glade's general catalog
as this branch is not merged into GTK+ proper yet. We'll move the widget to Glade's
catalog when this is done.
This is another step towards making GdkDisplayManager backend-agnostic.
Most of the backends profit from this as their atom implementations
where generic anyway - x11 needed that to allow multiple X displays and
broadway, quartz and wayland don't have the concept of displays.
The X11 backend still did things, so I only #if 0'd some code but did
not actually update anything.
Printing a web page without window.print (which still segfault),
that is Ctrl+P is fixed (does not attempt to execute the
source_changed_handler on a printeroptionwidget that has been
destroyed) by disconnecting this handler in the printeroptionwidget
finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=696622
If the GtkPrintJob is freed too early when the surface has been created
but the job hasn't been sent to the printer, it's possible that the
file print backend tries to write to the io chaneel when it is already
closed. This produces runtime critical warnings:
GLib-CRITICAL **: g_io_channel_write_chars: assertion `channel->is_writeable' failed
https://bugzilla.gnome.org/show_bug.cgi?id=685420
It can happen if the io channel has been closed. In that case
g_io_channel_write_chars() returns early because of a g_return macro
that checks if the io channel is writable. When returning from g_return
macros, the bytes written output parameter is not updated and the error
is not filled, so the error is not detected and the written variable is
used uninitialized. We should check the return value of
g_io_channel_write_chars() to break the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=685419
This reverts commit 666d10ec76.
This change severely broke any treeviews without horizontal
scrollbars. Basically, ellipsization never kicks in, and instead
the treeview content just extends outside the visible area,
rendering it inaccessible. This broke e.g. the control-center
keyboard shortcuts panel, the gnome-disks device list, etc etc.
In the case that the client is started directly by the compositor the
WAYLAND_SOCKET environment variable is set containing the fd to use that was
created by a socketpair.
This environment variable is consumed by a call to wl_display_connect so a
second call will not take advantage of it.
https://bugzilla.gnome.org/show_bug.cgi?id=697673
The creation is async, and the sidebar could be destroyed while the D-Bus proxy is being created.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Having the changes for composite widget templates makes it impossible
to merge the places-sidebar branch. So, we will merge that branch,
and *then* apply the changes for composite templates.
This reverts commit bf909f5615.
If gdk_window_flush_outstanding_moves() creates new update area
we handle this directly in the same draw to avoid flashing.
This mainly affects win32 as X11 does its exposes from moves async.
However, its important for win32 since ScrollDC seems to sometimes
invalidate (and not copy) unexected regions.
http://bugzilla.gnome.org/show_bug.cgi?674051
Rather than set the window update region and repaint this region
when we get a WM_PAINT we just directly add it to the update
region. No need to roundtrip via win32.
This lets us also make sure we do this drawing in the same update
cycle. This seems especially important on Win7, because ScrollDC
seems to act kind of weird there, not using bitblt in areas where
it seemingly could, which makes scrolling look really flashy.
http://bugzilla.gnome.org/show_bug-cgi?id=674051
