pidgin: 7aaca1d6: There was a little weirdness with the co...

[markdoliner at pidgin.im]

-----------------------------------------------------------------
Revision: 7aaca1d66aee8c4f1b292b419d8527c11fe85072
Ancestor: fa0c3fc6e6660e7a488bbaae03dc152b9925cc6c
Author: markdoliner at pidgin.im
Date: 2008-09-16T23:35:45
Branch: im.pidgin.pidgin
URL: http://d.pidgin.im/viewmtn/revision/info/7aaca1d66aee8c4f1b292b419d8527c11fe85072

Modified files:
        libpurple/dnsquery.c

ChangeLog: 

There was a little weirdness with the code that called the UI function
for resolving DNS queries.  I don't think this affects anyone I know
(not Pidgin, Finich, Adium or Meebo).  It would affect someone running
on Unix/Linux and using their own DNS resolution UI op.

And even then the functionality should basically remain the same...
The code is hopefully more clean this way in the event where
ops->resolve_hosts is defined, but returns FALSE for some odd reason.

-------------- next part --------------
============================================================
--- libpurple/dnsquery.c	c43b686683c20d229badf2a041df5182cc696771
+++ libpurple/dnsquery.c	1eea218d0ea86bb61dffb89b1897d4f0f3cea8a4
@@ -490,13 +490,6 @@ handle_next_queued_request(void)
 	query_data = queued_requests->data;
 	queued_requests = g_slist_delete_link(queued_requests, queued_requests);
 
-	if (purple_dnsquery_ui_resolve(query_data))
-	{
-		/* The UI is handling the resolve; we're done */
-		handle_next_queued_request();
-		return;
-	}
-
 	/*
 	 * If we have any children, attempt to have them perform the DNS
 	 * query.  If we're able to send the query then resolver will be
@@ -608,6 +601,12 @@ resolve_host(gpointer data)
 	query_data = data;
 	query_data->timeout = 0;
 
+	if (purple_dnsquery_ui_resolve(query_data))
+	{
+		/* The UI is handling the resolve; we're done */
+		return FALSE;
+	}
+
 	handle_next_queued_request();
 
 	return FALSE;