Re: _for_display() and _for_screen()
- From: Erwann Chenede <Erwann Chenede Sun COM>
- To: gtk-devel-list gnome org
- Cc: otaylor redhat com
- Subject: Re: _for_display() and _for_screen()
- Date: Thu, 25 Apr 2002 17:41:45 +0100 (BST)
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]