Am Donnerstag, den 20.12.2007, 11:46 -0500 schrieb Havoc Pennington:
> Hi,
>
> Mathias Hasselmann wrote:
> > Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
> >
> >> Then the following default implementations:
> >>
> >> - all four of the new functions have default implementations that
> >> invoke the current size_request and use it for both min and natural
> >> size; so unmodified widgets still support the new interface
> >
> > So you suggest, that GtkWidget implements GtkExtendedLayout?
>
> Several factors I can think of here.
>
> First when implementing each container, it would be nice to avoid:
>
> if (is_extended_layout(child)) {
> use new request API
> } else {
> use old size request API
> }
>
> One solution would be that GtkWidget automatically implements extended
> layout in terms of size request. Another solution would be just a
> convenience function that does the above.
Yes, it makes sense to implement GtkExtendedLayout at GtkWidget level
already. This step has quite some potential to simplify code.
> I'm guessing your patch already had a solution to this, I don't remember
> what it was.
>
> Two, when implementing a widget, it would be good to avoid writing both
> the old size request and the new extended layout. So, one way to do that
> is that in GtkWidget there's a default implementation of size request
> that invokes extended layout. This may require GtkWidget to implement
> extended layout, or maybe the default impl of size request could do
> GTK_IS_EXTENDED_LAYOUT(), that might be fine too. Then GtkWidget would
> not have to implement extended layout.
The solution I used, was adding a flag, respectively a callback to the
old size_request method indicating the operation mode (minimum
size/natural size). My size_request implementation called that now
internal function with minimum-size arguments, the natural_size
implementation called with natural-size arguments.
Ugly, compared to the smart choice of fallback behavior you suggest.
I'll modify my patches, so that all containers directly use the extended
layout interface, without any if/else mambo for child measurement.
> Third, since implementing an interface requires extra boilerplate
> GObject stuff, it would be convenient for authors of a custom widget if
> GtkWidget already did the boilerplate for them. Since for newly-written
> custom widgets, the recommendation would be to always support extended
> layout.
I don't see the boilerplate savings you talk about? As far as I
understand GObject interfaces, you always need this this single-line
boilerplate for overriding interface methods:
G_DEFINE_TYPE_WITH_CODE (MamanBar, maman, GTK_TYPE_WIDGET,
G_IMPLEMENT_INTERFACE (GTK_TYPE_IFACE, maman_bar_iface_init))
Ciao,
Mathias
--
Mathias Hasselmann <mathias hasselmann gmx de>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil