_for_display() and _for_screen()

[Owen Taylor <otaylor redhat com>]

Working on merging the multihead branch, I've come to the conclusion 
that I'm not entirely happy with the naming scheme that Erwann and
I worked out earlier for multihead functions. 

In the current multihead branch, some functions that natural relate to
a GdkScreen or GdkDisplay object become methods on GdkScreen and
GdkScreen, for example:

 gdk_pointer_ungrab    =>  gdk_display_pointer_ungrab
 gdk_get_screen_width  =>  gdk_screen_get_width

But a large number simply get a "for_screen() or for_display() suffix".

 gdk_list_visuals           => gdk_list_visuals_for_screen()
 gdk_setting_get            => gdk_setting_get_for_screen()
 gdk_set_double_click_time  => gdk_set_double_click_time_for_display

What I want to do is go with the rule that for_display() and
for_screen() suffixes are used only:

 * For constructors and functions that return a singleton object, e.g.:

    gdk_cursor_new_for_screen
    gdk_keymap_get_for_display

 * For functions where the GdkDisplay is needed only for obscure
   implementation reasons, e.g.:

    gdk_string_to_compound_text_for_display
    gdk_text_property_to_text_list_for_display

 * For certain obscure gdk/gtk functions 

    gdk_selection_send_notify_for_display
    gdk_drag_get_protocol_for_display

So, the renames I want to do as compared to the multihead branch are:

 gdk_add_client_message_filter_for_display      => gdk_display_add_client_message_filter
 gdk_colormap_get_system_for_screen             => gdk_screen_get_system_colormap
 gdk_devices_list_for_display                   => gdk_display_list_devices
 gdk_event_send_clientmessage_toall_for_screen  => gdk_screen_broadcast_client_message
 gdk_list_visuals_for_screen                    => gdk_screen_list_visuals
 gdk_net_wm_supports_for_screen                 => gdk_screen_net_wm_supports
 gdk_pango_context_get_for_screen               => gdk_screen_get_pango_context
 gdk_rgb_get_colormap_for_screen                => gdk_screen_get_rgb_colormap
 gdk_rgb_get_visual_for_screen                  => gdk_screen_get_rgb_visual
 gdk_set_double_click_time_for_display          => gdk_display_set_double_click_time
 gdk_set_sm_client_id_for_display               => gdk_display_set_sm_client_id 
 gdk_setting_get_for_screen                     => gdk_screen_get_setting
 gdk_visual_get_system_for_screen               => gdk_screen_get_system_visual
 gdk_window_get_toplevels_for_screen            => gdk_screen_get_toplevels

_for_screen and _for_display functions that would remain are:

 gdk_cursor_new_for_screen
 gdk_drag_get_protocol_for_display 
 gdk_font_from_description_for_display
 gdk_font_load_for_display
 gdk_fontset_load_for_display
 gdk_keymap_get_for_display
 gdk_pixmap_foreign_new_for_display
 gdk_window_foreign_new_for_display

 gdk_event_send_client_message_for_display
 gdk_string_to_compound_text_for_display
 gdk_text_property_to_text_list_for_display
 gdk_text_property_to_utf8_list_for_display
 gdk_utf8_to_compound_text_for_display

 gdk_selection_owner_get_for_display
 gdk_selection_owner_set_for_display
 gdk_selection_send_notify_for_display

 gdk_x11_atom_to_xatom_for_display
 gdk_x11_get_xatom_by_name_for_display
 gdk_x11_get_xatom_name_for_display
 gdk_x11_xatom_to_atom_for_display

I think these changes will make the new API a fair bit more logical and
more attractive.

They shouldn't have much effect on the GTK+ part of the patch or the
work Wipro has been doing on making GNOME components multihead aware
since these changes don't affect the most common multihead changes,
and since they are just mechanical name changes.

Regards,
                                        Owen