Re: EggDateTime committed to libegg

[Bill Haneman <bill haneman sun com>]

Hi:
<snip>
...
> The widget consists
> of a GtkEntry for the date with a calendar popup button and a GtkEntry
> for the time with a time list popup button. So it's fairly easy to
> provide two methods:
> 
>   PangoLayout *egg_datetime_get_date_layout (EggDateTime *eggdatetime);
>   PangoLayout *egg_datetime_get_time_layout (EggDateTime *eggdatetime);
> 
> But this has one major disadvantage: It exposes the setup of the widget
> in the API; we can't change the composition of the widget later (e.g. we
> can't replace the two entries by one combined entry) if we commit to this
> API.

If we wanted something more general, we'd need a list/array of layouts,
and names for each layout.  That'd be fine, i.e.

gint egg_datatime_get_layouts (EggDataTime *edt, PangoLayout  
                               **layout_rtn, gchar **names_rtn);	

or perhaps returning a GList of DateTimeLayoutStructs would be cleaner:

typedef struct {
	gchar *name;
	PangoLayout *layout;
} DateTimeLayout;

> > Why do we need this?  Well, in order to implement AtkText on a widget,
> > we need access to glyph bounds for every displayed character, among
> > other things.
> 
> Is AtkText really the right object for date/time display? If so, can't
> the widget provide an AtkText object itself?

Anything that puts textual info on the screen needs to expose AtkText,
so the answer to the first question is "yes".  As for the second, the
policy of GTK+ is to put all ATK implementation code in libgail; other
widget libraries can and do provide their own ATK implementations
internally, but for GTK+ widgets, externalizing the implementation means
that the required internal info must be exposed to GAIL via API.

regards,

Bill

>  - Sebastian