AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
3023d254dd
gtk2/gdk/gdkdndprivate.h

129 lines
5.2 KiB
C
Raw Normal View History

Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
/* GDK - The GIMP Drawing Kit
* Copyright (C) 2010, Red Hat, Inc
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
Change FSF Address
2012-02-27 13:01:10 +00:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
*/
#ifndef __GDK_DND_PRIVATE_H__
#define __GDK_DND_PRIVATE_H__
#include "gdkdnd.h"
G_BEGIN_DECLS
Consistently hide class structs And, since we've decided to keep the structs private, there is no point in having the standard GObject clas macros anymore either.
2010-12-24 20:54:12 +00:00
#define GDK_DRAG_CONTEXT_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), GDK_TYPE_DRAG_CONTEXT, GdkDragContextClass))
#define GDK_IS_DRAG_CONTEXT_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), GDK_TYPE_DRAG_CONTEXT))
#define GDK_DRAG_CONTEXT_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GDK_TYPE_DRAG_CONTEXT, GdkDragContextClass))
typedef struct _GdkDragContextClass GdkDragContextClass;
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
struct _GdkDragContextClass {
GObjectClass parent_class;
GdkWindow * (*find_window) (GdkDragContext *context,
GdkWindow *drag_window,
gint x_root,
gint y_root,
GdkDragProtocol *protocol);
GdkAtom (*get_selection) (GdkDragContext *context);
gboolean (*drag_motion) (GdkDragContext *context,
GdkWindow *dest_window,
GdkDragProtocol protocol,
gint root_x,
gint root_y,
GdkDragAction suggested_action,
GdkDragAction possible_actions,
guint32 time_);
void (*drag_status) (GdkDragContext *context,
GdkDragAction action,
guint32 time_);
void (*drag_abort) (GdkDragContext *context,
guint32 time_);
void (*drag_drop) (GdkDragContext *context,
guint32 time_);
void (*drop_reply) (GdkDragContext *context,
gboolean accept,
guint32 time_);
void (*drop_finish) (GdkDragContext *context,
gboolean success,
guint32 time_);
gboolean (*drop_status) (GdkDragContext *context);
Add gdk_drag_context_get_drag_window This makes gdk_wayland_drag_context_get_dnd_window backend-independent API and adds an implementation for X11.
2015-12-02 04:33:53 +00:00
GdkWindow* (*get_drag_window) (GdkDragContext *context);
gdk: Add api to set drag window hotspot With GdkDragContext now being in charge of placing the window, it needs to know about the hotspot to place under the cursor.
2015-12-08 02:52:03 +00:00
void (*set_hotspot) (GdkDragContext *context,
gint hot_x,
gint hot_y);
gdk: Add gdk_drag_drop_done This will allow us to move the drag cancel animation to GDK. For now, it does nothing.
2015-12-07 20:07:13 +00:00
void (*drop_done) (GdkDragContext *context,
gboolean success);
gdk: Allow internal management of source-side DnD We've traditionally left GTK+ to handle the input side of things, letting GDK only manage the windowing-specific messaging. This way of splitting responsibilities is not compatible however with some backends, we must fold then input management at the DnD stage into GDK (and backends) domain. The gdk_drag_context_manage_dnd() call is meant to be the entry point for this mode of operation, if the drag and drop operation becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform grabs, nor manage input events itself. As a consequence of this, different aspects now belong to the backend GdkDragContext implementation: - Because the caller doesn't see keyboard events anymore, keyboard navigation must be managed in GDK, so is the decision of the current action based on modifiers/button pressed. - Because the caller won't see input events in general, the lifetime of the drag and drop operation is now communicated through the ::drop-performed, ::dnd-finished and ::cancel events - Because the caller doesn't participate anymore on the action being chosen, the pointer cursor must be set by the backend. The caller is rather notified of the final action through the ::action signal. The caller is still responsible of dealing with the corresponding GdkSelection, ensuring its ownership and communicating the supported mimetypes.
2016-01-08 20:03:01 +00:00
gboolean (*manage_dnd) (GdkDragContext *context,
GdkWindow *ipc_window,
GdkDragAction actions);
void (*set_cursor) (GdkDragContext *context,
GdkCursor *cursor);
gdk: Add GdkDragCancelReason enum as argument to GdkDragContext::cancel We should conform to a minimal set of reasons for the gtk side to emit a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET. In the wayland side, unfortunately we can't honor either NO_TARGET nor USER_CANCELLED, we don't know of the latter, so we could return false positives on the former. https://bugzilla.gnome.org/show_bug.cgi?id=761954
2016-02-15 16:02:14 +00:00
void (*cancel) (GdkDragContext *context,
GdkDragCancelReason reason);
gdk: Allow internal management of source-side DnD We've traditionally left GTK+ to handle the input side of things, letting GDK only manage the windowing-specific messaging. This way of splitting responsibilities is not compatible however with some backends, we must fold then input management at the DnD stage into GDK (and backends) domain. The gdk_drag_context_manage_dnd() call is meant to be the entry point for this mode of operation, if the drag and drop operation becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform grabs, nor manage input events itself. As a consequence of this, different aspects now belong to the backend GdkDragContext implementation: - Because the caller doesn't see keyboard events anymore, keyboard navigation must be managed in GDK, so is the decision of the current action based on modifiers/button pressed. - Because the caller won't see input events in general, the lifetime of the drag and drop operation is now communicated through the ::drop-performed, ::dnd-finished and ::cancel events - Because the caller doesn't participate anymore on the action being chosen, the pointer cursor must be set by the backend. The caller is rather notified of the final action through the ::action signal. The caller is still responsible of dealing with the corresponding GdkSelection, ensuring its ownership and communicating the supported mimetypes.
2016-01-08 20:03:01 +00:00
void (*drop_performed) (GdkDragContext *context,
guint32 time);
void (*dnd_finished) (GdkDragContext *context);
gboolean (*handle_event) (GdkDragContext *context,
const GdkEvent *event);
void (*action_changed) (GdkDragContext *context,
GdkDragAction action);
gdkdnd: Add private means to commit the drag status The way gdk_drag_status() may be called multiple times during the processing of drag and drop events throughout the widget hierarchy brings some superfluous messaging going in, esp. when it's the last request the one we want to honor, yet we emit messaging requests on all. This is barely appreciable in the X11 backend, but due to the design of the wayland protocol, quick series of changes like this it have some self-amplificating consequences which may end up flooding the connection. We can delegate this to a late "commit" call, performed within GDK event management. This way gdk_drag_status() calls may be cached and only result in windowing messaging once per ::drag-motion or ::drag-data-received event. Emitting the final status will also avoid spurious action changes on the compositor and the other peer. https://bugzilla.gnome.org/show_bug.cgi?id=763298
2016-03-09 16:00:31 +00:00
void (*commit_drag_status) (GdkDragContext *context);
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
};
struct _GdkDragContext {
GObject parent_instance;
Fix up GDK docs
2010-12-25 05:02:39 +00:00
/*< private >*/
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
GdkDragProtocol protocol;
gdk/dnd: Don't use default display when getting cursor Always associate a drag context with a GdkDisplay and use that when getting a cursor for a given action. If we don't do this, dragging on a window that doesn't use the default display will make us use cursors from the wrong display. https://bugzilla.gnome.org/show_bug.cgi?id=765565
2016-04-26 07:31:33 +00:00
GdkDisplay *display;
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
gboolean is_source;
GdkWindow *source_window;
GdkWindow *dest_window;
Add gdk_drag_context_get_drag_window This makes gdk_wayland_drag_context_get_dnd_window backend-independent API and adds an implementation for X11.
2015-12-02 04:33:53 +00:00
GdkWindow *drag_window;
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
gdkdnd: Make GdkDragContext->formats a GdkContentFormats Instead of it being a GList of GdkAtoms.
2017-11-18 04:53:25 +00:00
GdkContentFormats *formats;
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
GdkDragAction actions;
GdkDragAction suggested_action;
GdkDragAction action;
guint32 start_time;
GdkDevice *device;
gdkdnd: Stick to the first gdk_drag_drop_done() result That way we can let ::cancel callers to override the visual result of the operation (eg. when detaching notebook tabs on NO_TARGET). Also, document gdk_drag_drop_done() so it is mentioned that this is a one-shot call. https://bugzilla.gnome.org/show_bug.cgi?id=761954
2016-02-15 17:56:42 +00:00
guint drop_done : 1; /* Whether gdk_drag_drop_done() was performed */
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
};
gdk: Allow internal management of source-side DnD We've traditionally left GTK+ to handle the input side of things, letting GDK only manage the windowing-specific messaging. This way of splitting responsibilities is not compatible however with some backends, we must fold then input management at the DnD stage into GDK (and backends) domain. The gdk_drag_context_manage_dnd() call is meant to be the entry point for this mode of operation, if the drag and drop operation becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform grabs, nor manage input events itself. As a consequence of this, different aspects now belong to the backend GdkDragContext implementation: - Because the caller doesn't see keyboard events anymore, keyboard navigation must be managed in GDK, so is the decision of the current action based on modifiers/button pressed. - Because the caller won't see input events in general, the lifetime of the drag and drop operation is now communicated through the ::drop-performed, ::dnd-finished and ::cancel events - Because the caller doesn't participate anymore on the action being chosen, the pointer cursor must be set by the backend. The caller is rather notified of the final action through the ::action signal. The caller is still responsible of dealing with the corresponding GdkSelection, ensuring its ownership and communicating the supported mimetypes.
2016-01-08 20:03:01 +00:00
GList * gdk_drag_context_list (void);
void gdk_drag_context_set_cursor (GdkDragContext *context,
GdkCursor *cursor);
gdk: Add GdkDragCancelReason enum as argument to GdkDragContext::cancel We should conform to a minimal set of reasons for the gtk side to emit a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET. In the wayland side, unfortunately we can't honor either NO_TARGET nor USER_CANCELLED, we don't know of the latter, so we could return false positives on the former. https://bugzilla.gnome.org/show_bug.cgi?id=761954
2016-02-15 16:02:14 +00:00
void gdk_drag_context_cancel (GdkDragContext *context,
GdkDragCancelReason reason);
gdk: Allow internal management of source-side DnD We've traditionally left GTK+ to handle the input side of things, letting GDK only manage the windowing-specific messaging. This way of splitting responsibilities is not compatible however with some backends, we must fold then input management at the DnD stage into GDK (and backends) domain. The gdk_drag_context_manage_dnd() call is meant to be the entry point for this mode of operation, if the drag and drop operation becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform grabs, nor manage input events itself. As a consequence of this, different aspects now belong to the backend GdkDragContext implementation: - Because the caller doesn't see keyboard events anymore, keyboard navigation must be managed in GDK, so is the decision of the current action based on modifiers/button pressed. - Because the caller won't see input events in general, the lifetime of the drag and drop operation is now communicated through the ::drop-performed, ::dnd-finished and ::cancel events - Because the caller doesn't participate anymore on the action being chosen, the pointer cursor must be set by the backend. The caller is rather notified of the final action through the ::action signal. The caller is still responsible of dealing with the corresponding GdkSelection, ensuring its ownership and communicating the supported mimetypes.
2016-01-08 20:03:01 +00:00
gboolean gdk_drag_context_handle_source_event (GdkEvent *event);
gdkdnd: Add private means to commit the drag status The way gdk_drag_status() may be called multiple times during the processing of drag and drop events throughout the widget hierarchy brings some superfluous messaging going in, esp. when it's the last request the one we want to honor, yet we emit messaging requests on all. This is barely appreciable in the X11 backend, but due to the design of the wayland protocol, quick series of changes like this it have some self-amplificating consequences which may end up flooding the connection. We can delegate this to a late "commit" call, performed within GDK event management. This way gdk_drag_status() calls may be cached and only result in windowing messaging once per ::drag-motion or ::drag-data-received event. Emitting the final status will also avoid spurious action changes on the compositor and the other peer. https://bugzilla.gnome.org/show_bug.cgi?id=763298
2016-03-09 16:00:31 +00:00
gboolean gdk_drag_context_handle_dest_event (GdkEvent *event);
gdk/dnd: Don't use default display when getting cursor Always associate a drag context with a GdkDisplay and use that when getting a cursor for a given action. If we don't do this, dragging on a window that doesn't use the default display will make us use cursors from the wrong display. https://bugzilla.gnome.org/show_bug.cgi?id=765565
2016-04-26 07:31:33 +00:00
GdkCursor * gdk_drag_get_cursor (GdkDragContext *context,
GdkDragAction action);
gdk: Allow internal management of source-side DnD We've traditionally left GTK+ to handle the input side of things, letting GDK only manage the windowing-specific messaging. This way of splitting responsibilities is not compatible however with some backends, we must fold then input management at the DnD stage into GDK (and backends) domain. The gdk_drag_context_manage_dnd() call is meant to be the entry point for this mode of operation, if the drag and drop operation becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform grabs, nor manage input events itself. As a consequence of this, different aspects now belong to the backend GdkDragContext implementation: - Because the caller doesn't see keyboard events anymore, keyboard navigation must be managed in GDK, so is the decision of the current action based on modifiers/button pressed. - Because the caller won't see input events in general, the lifetime of the drag and drop operation is now communicated through the ::drop-performed, ::dnd-finished and ::cancel events - Because the caller doesn't participate anymore on the action being chosen, the pointer cursor must be set by the backend. The caller is rather notified of the final action through the ::action signal. The caller is still responsible of dealing with the corresponding GdkSelection, ensuring its ownership and communicating the supported mimetypes.
2016-01-08 20:03:01 +00:00
Explode gdkinternals.h into per-class private headers At the same time, move some more class and instance structs out of public headers.
2010-12-11 05:14:53 +00:00
G_END_DECLS
#endif
Reference in New Issue Copy Permalink