After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 634541 - GtkEntry::button and GtkEntry::in_drag setters
GtkEntry::button and GtkEntry::in_drag setters
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkEntry
2.99.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on: 610515
Blocks: 597610
 
 
Reported: 2010-11-10 20:07 UTC by Morten Welinder
Modified: 2018-04-15 00:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Morten Welinder 2010-11-10 20:07:35 UTC
I need a way to set GtkEntry::button

Or rather, I need a way to reset a GtkEntry to its normal state when
it is not going to get the button-release event it is waiting for.
That, in turn, happens when a focus-in handler throws up a dialog.

Code from Gnumeric:

static gboolean
cb_editline_focus_in (GtkWidget *w, GdkEventFocus *event,
		      WBCGtk *wbcg)
{
	if (!wbcg_is_editing (wbcg))
		if (!wbcg_edit_start (wbcg, FALSE, TRUE)) {
			GtkEntry *entry = GTK_ENTRY (w);
			wbcg_focus_cur_scg (wbcg);
			entry->in_drag = FALSE;
			/*
			 * ->button is private, ugh.  Since the text area
			 * never gets a release event, there seems to be
			 * no official way of returning the widget to its
			 * correct state.
			 */
			entry->button = 0;
			return TRUE;
		}

	return FALSE;
}
Comment 1 Morten Welinder 2010-11-11 20:06:33 UTC
To reset, I also need to set ::in_drag.  (Unlike ::button that used to be
public.).
Comment 2 Christian Dywan 2010-12-03 15:53:24 UTC
This would seem to overlap with bug 610515.
Comment 3 Timothy Arceri 2013-10-14 06:45:54 UTC
Did this make it into GTK+3? Is this bug still relevant?
Comment 4 Matthias Clasen 2018-02-10 05:25:03 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 5 Matthias Clasen 2018-04-15 00:33:18 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new