[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Extended Layout Summary
From:       Havoc Pennington <hp () redhat ! com>
Date:       2007-12-20 16:46:44
Message-ID: 476A9C74.3070507 () redhat ! com
[Download RAW message or body]

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.

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.

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.

Those are the factors I can think of. I might be wrong about them, or 
there may be other factors that are also important and that lead to the 
opposite conclusion.

Havoc

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]