Re: _for_display() and _for_screen()



Hi Owen,

It make sense, do you intend to move the declaration and implementation 
of all the renamed functions to gdkscreen.[hc] gdkdisplay.[hc] or just
leave them as scattered across files as is ?

	Best Regards,
	Erwann 

>
>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

 Erwann Chénedé, Sun Microsystems, Ireland
 Phone  : +353 1 8199031         xt: 19031
[ I speak for myself, not for my employer ]





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]