Re: padding cleanup
On Wed, Sep 15, 2010 at 5:21 AM, Murray Cumming murr...@murrayc.com wrote: I haven't followed this in detail, but I see the new GtkWidget align and margin-* properties and functions: http://git.gnome.org/browse/gtk +/commit/?id=474f80442a6f3cf72a3c3b9efc5a846e7664d758 So will things like gtk_alignment_set() be deprecated soon? http://library.gnome.org/devel/gtk/unstable/GtkAlignment.html#gtk-alignment-set The current thinking is that GtkMisc and GtkAlignment will stay around deprecated in 3, and will be removed for good in GTK4. So yes, we should probably mark them as deprecated in master. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On 13.09.2010 04:50, Havoc Pennington wrote: Hi, I merged the main patch to master. I wrote docs (see attached) but did not push them yet because I can't figure out how to actually document a non-signal virtual function in a non-interface. Yes, docuemnt is as part of the class structure. What I have here puts the text of the docs in the HTML but it doesn't look nice. Does gtk-doc just not do this? Its a bit uncommon to do it like you did in gtk/gtkwidget.h. Just do: *...@adjust_size_request: Convert·an·initial·size·request·from·a·widget's·#GtkSizeRequest * virtual·method·implementations·into·a·size·request·to·be·used·by ... Stefan Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Sun, Sep 12, 2010 at 6:21 AM, Havoc Pennington h...@pobox.com wrote: Something that occurred to me mid-bisect is that with Benjamin's draw() work, it would probably be straightforward to write the following test program: * instantiate every widget type in GTK (or even various modes of every widget type, like different text styles, wrap or not, padding/border or not, etc.) * dump a giant directory of PNGs representing the paint of every one of those in every GtkStateType Uh, you've found out about one of my secret projects. Actually, what I'm aiming at is reftests (see http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html for a description). They are independant of font settings, themes etc if done right. A big problem with comparing a rendering to a default image - unless you do it manually, and then you won't find a lot of issues like 1px offsets - is that so many things can change that you do not have under control that end up screwing up your comparisons. Even perceptual diffs don't help you there. Cairo's test suite works like this (comparing renderings to a reference image), and we have often have to regenerate images for new versions of pixman, freetype or even the Deja Vu fonts. And every time we do that, it's a tedious manual process because we have to make sure that the images are at still correct. We also often have to keep reference images for all the different surface types because font or gradient rendering algorithms differ from OS X to Linux or even from Cairo's image surface to X. So I'd strongly recommend not comparing to reference images if you can avoid it. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Sun, Sep 12, 2010 at 6:44 AM, Benjamin Otte o...@gnome.org wrote: Uh, you've found out about one of my secret projects. Actually, what I'm aiming at is reftests (see http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html for a description). They are independant of font settings, themes etc if done right. Sounds cool! A big problem with comparing a rendering to a default image - unless Yeah, agreed that an automated test where canonical images were checked into git would probably keep breaking in annoying ways. I do think it'd be easier than Cairo - or at least, certain tests would be pretty robust. For example, if you packed various colored rectangles into GtkHBox with different packing parameters, I don't think that would have changed its pixels in years - it's not quite like Cairo where you're doing the complex antialiasing and so forth, and the exact pixels rendered aren't necessarily defined. If I have an event box with background color 0xff and I set its size request and pack it into a GtkBox, then that just can't change unless a GTK API has changed. Possibly some font - or fake font that's just full of boxes - could be shipped with GTK to keep text rendering stuff from interfering. However the automated tests are done, just having a toolset for rendering out a bunch of useful widget images as PNGs will be awfully handy. Some use-cases: * smoke-test a patch. if I mess with GDK or cairo or size requesting, if I could build and render a set of before images on my machine locally, and also a set of after images, and quickly do an automated diff - there's no pixman changed or font changed issues since it's all on my machine, no canonical images located in git - I could see if I triggered any g_warning() or changed how anything paints, without having to manually walk through gtk-demo/testgtk and look for broken stuff, which is what I've been doing * quick-check a theme. sort of like metacity-theme-viewer which shows windows in a bunch of states * write git-bisect scripts. for example it probably would have been worthwhile to automate bisecting that bug we just bisected, by writing a little git bisect run program to render the good and bad insensitive label. Anyway however it works, clearly your draw() work is going to enable it, and this has got to be a giant win from that work. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Sun, Sep 12, 2010 at 1:19 PM, Havoc Pennington h...@pobox.com wrote: Hi, I pushed a widget-padding-2 branch which has everything cleaned up. Both widget-padding and widget-padding-2 can be deleted once this is merged. (I can merge if you like or feel free. or let me know what else to change.) Please go ahead and merge it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, I merged the main patch to master. I wrote docs (see attached) but did not push them yet because I can't figure out how to actually document a non-signal virtual function in a non-interface. What I have here puts the text of the docs in the HTML but it doesn't look nice. Does gtk-doc just not do this? Havoc From 218ab01aa87e9344f6708ae32d74503014508905 Mon Sep 17 00:00:00 2001 From: Havoc Pennington h...@pobox.com Date: Sun, 12 Sep 2010 21:43:39 -0400 Subject: [PATCH] Add documentation on adjust_size_request adjust_size_allocation Also note in the docs for various other functions, whether they use adjusted or parent container size allocation. --- gtk/gtksizerequest.c | 59 ++ gtk/gtkwidget.c | 28 ++- gtk/gtkwidget.h | 36 ++ 3 files changed, 121 insertions(+), 2 deletions(-) diff --git a/gtk/gtksizerequest.c b/gtk/gtksizerequest.c index 543bbc1..8ae2662 100644 --- a/gtk/gtksizerequest.c +++ b/gtk/gtksizerequest.c @@ -87,6 +87,34 @@ * width. By following this rule any widget that handles height-for-width * or width-for-height requests will always be allocated at least * enough space to fit its own content. + * + * Often a widget needs to get its own request during size request or + * allocation, for example when computing height it may need to also + * compute width, or when deciding how to use an allocation the widget may + * need to know its natural size. In these cases, the widget should be + * careful to call its virtual methods directly, like this: + * example + * titleWidget calling its own size request method./title + * programlisting + * GTK_SIZE_REQUEST_GET_IFACE(widget)-gt;get_width(GTK_SIZE_REQUEST(widget), min, natural); + * /programlisting + * /example + * + * It will not work to use the wrapper functions, such as + * gtk_size_request_get_width(), inside your own size request + * implementation. These return a request adjusted by #GtkSizeGroup + * and by the GtkWidgetClass::adjust_size_request virtual method. If a + * widget used the wrappers inside its virtual method implementations, + * then the adjustments (such as widget margins) would be applied + * twice. GTK+ therefore does not allow this and will warn if you try + * to do it. + * + * Of course if you are getting the size request for + * emphasisanother/emphasis widget, such as a child of a + * container, you emphasismust/emphasis use the wrapper APIs; + * otherwise, you would not properly consider widget margins, + * #GtkSizeGroup, and so forth. + * * /para * /refsect2 */ @@ -423,6 +451,12 @@ gtk_size_request_get_request_mode (GtkSizeRequest *widget) * noteparaThis call is specific to height-for-width * requests./para/note * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * * Since: 3.0 */ void @@ -445,6 +479,13 @@ gtk_size_request_get_width (GtkSizeRequest *widget, * * noteparaThis call is specific to width-for-height requests./para/note * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * + * * Since: 3.0 */ void @@ -468,6 +509,12 @@ gtk_size_request_get_height (GtkSizeRequest *widget, * Retrieves a widget's minimum and natural width if it would be given * the specified @height. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * * Since: 3.0 */ void @@ -490,6 +537,12 @@ gtk_size_request_get_width_for_height (GtkSizeRequest *widget, * Retrieves a widget's minimum and natural height if it would be given * the specified @width. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned request + * is the one that should be used for layout, not necessarily the one + * returned by the widget itself. + * * Since: 3.0 */ void @@ -514,6 +567,12 @@ gtk_size_request_get_height_for_width (GtkSizeRequest *widget, * This is used to retrieve a suitable size by container widgets which do * not impose any restrictions on the child placement. * + * The returned request will be modified by the + * GtkWidgetClass::adjust_size_request virtual method and by any + * #GtkSizeGroup that have been applied. That is, the returned
Re: padding cleanup
Hi, On Sat, Sep 11, 2010 at 11:41 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Turns out this is unrelated to your branch. I've bisected this to Oops, I just burnt a hole in my lap bisecting this too. At least _one_ of those checkouts could have managed not to rebuild the whole tree... I got to this commit though, one after yours, as the guilty one (for me ccacd3a was OK) commit 709e05cdb20fd6d2360b7158286d6c3176c300c0 Author: Benjamin Otte o...@redhat.com Date: Sat Aug 7 02:18:06 2010 +0200 style: Use _gtk_pango_fill_layout() Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Sat, 2010-09-04 at 15:59 -0400, Havoc Pennington wrote: Hi, On Sat, Sep 4, 2010 at 1:40 PM, Thomas Wood t...@gnome.org wrote: It might be worth re-using the CSS box model¹ nomenclature here to avoid confusion. In the CSS box model: * margin: extra spacing around the element, outside of the border. * border: the width of the frame drawn around an element. * padding: the spacing between the content area and the border. The border property may not be strictly necessary, although might be useful for themes. Any other spacing between elements inside a widgets could be referred to with spacing properties. It's fairly unclear and ambiguous how to apply this to GTK. There isn't a frame drawn around elements. Prior to adding a patch like the one I'm proposing, there also is no distance between content area and border. Most of what's called padding in gtk now is probably margin - except that it goes with the container and not the widget. If we add just one kind of extra space around a widget, and it would not be included in the allocation the widget gets (which is true in the implementation I proposed most recently), then I guess the widget won't draw its background in this space. And there won't be any color or anything there. So maybe what I'm suggesting we add is best called margin. I would agree. Your new properties refer to extra spacing added around the widget, so the margin name would make the most sense in terms of the W3C box model. Regards, Thomas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Cool. So I'm inclined to search-and-replace the patch and make the properties: margin-left margin-right margin-top margin-bottom margin /* sets all four at once */ I'll give it a couple more days though in case this turns out to be controversial so I don't do too much busywork ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Tue, Sep 7, 2010 at 9:41 AM, Havoc Pennington h...@pobox.com wrote: Cool. So I'm inclined to search-and-replace the patch and make the properties: margin-left margin-right margin-top margin-bottom margin /* sets all four at once */ I'll give it a couple more days though in case this turns out to be controversial so I don't do too much busywork ;-) Sounds fine to me, fwiw. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
https://bugzilla.gnome.org/show_bug.cgi?id=628828 has a patch ready for review. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Thu, 2010-09-02 at 19:58 -0400, Havoc Pennington wrote: And here are some of the 'layout' style properties: I think we could add style props on GtkWidget that would modify the padding on the widget (I don't know if they'd just replace the programmer-set padding, or be an adjustment to it?). That would be simple once GtkWidget has padding, I think. I don't know if the widget style props would replace most of these though - it looks like most of these paddings and spacings are somewhere inside a widget, not on the border. It might be worth re-using the CSS box model¹ nomenclature here to avoid confusion. In the CSS box model: * margin: extra spacing around the element, outside of the border. * border: the width of the frame drawn around an element. * padding: the spacing between the content area and the border. The border property may not be strictly necessary, although might be useful for themes. Any other spacing between elements inside a widgets could be referred to with spacing properties. Regards, Thomas ¹http://www.w3.org/TR/CSS2/box.html#box-dimensions ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Thu, Sep 2, 2010 at 6:14 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Of course, this only handles the size_request side of things. It would be up to individual containers to respect the h/v-align in their size_allocate (basically replacing their current child properties), correct ? Couldn't we do it in gtk_widget_size_allocate ? I can just try this patch and any reason it won't work may become clear quickly One thing that is not addressed yet is how we will split this between application control and theme control. To illustrate the point, here is the list of 'layout' properties we have currently: GtkAlignment::bottom-padding GtkAlignment::left-padding GtkAlignment::right-padding GtkAlignment::top-padding GtkContainer::border-width GtkMisc::xalign GtkMisc::yalign GtkMisc::xpad GtkMisc::ypad The above would all be replaced by GtkWidget props I think GtkBox::spacing GtkButtonBox::layout-style GtkTable::column-spacing GtkTable::row-spacing GtkExpander::spacing These would remain as container-specific probably (though I don't really know what Expander::spacing is and didn't look) And here are some of the 'layout' style properties: I think we could add style props on GtkWidget that would modify the padding on the widget (I don't know if they'd just replace the programmer-set padding, or be an adjustment to it?). That would be simple once GtkWidget has padding, I think. I don't know if the widget style props would replace most of these though - it looks like most of these paddings and spacings are somewhere inside a widget, not on the border. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Sun, 2010-08-29 at 19:02 -0400, Havoc Pennington wrote: Hi, Matthias's mention of padding props got me thinking about how this could be mopped up (based shamelessly on what we did in HippoCanvas and then BigBox) I'm attaching a patch that I haven't even tried to compile (my jhbuild setup is kinda hosed, don't ask) illustrating what I might like to see if starting from scratch. In brief it adds to GtkWidget: h-align, v-align = FILL, CENTER, START, END padding-left,padding-right,padding-top, padding-bottom = int16 Would it be better to have padding-start and padding-end, rather than -left and -right, and have it do the right thing in RTL locales? I've often wished CSS did it that way, and GTK+ does do most things with start and end already. -- Shaun McCance http://syllogist.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Wed, Sep 1, 2010 at 12:24 PM, Shaun McCance sha...@gnome.org wrote: Would it be better to have padding-start and padding-end, rather than -left and -right, and have it do the right thing in RTL locales? I've often wished CSS did it that way, and GTK+ does do most things with start and end already. Hmm. does GTK usually do that or does it just name them left and right and then flip left and right in RTL? Problem with start and end is it doesn't convey vertical vs. horizontal. I guess you could do hpadding-start hpadding-end. Still isn't the RTL support based on the app developer just thinking LTR and then GTK inverting everything? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Wed, Sep 1, 2010 at 2:03 PM, Shaun McCance sha...@gnome.org wrote: Well, all of the packing functions use start and end, but I guess that's just to make the term orientation-neutral. Looking through the docs, I do see properties like left-attach, left-margin, and left-padding. So it doesn't make sense to use start and end unless we switch all terminology. That's probably just pointless API churn. Side note: browsers are starting to provide properties using start and end: http://help.dottoro.com/lcedmdkb.php Well, what does GtkAlignment do already with its padding? I think the question is, does GTK just flip left and right, or does GTK let you choose to force left/right regardless of text direction and then also let you virtualize with start/end. I'd guess the browsers are not comfortable / unable to just flip all lefts and rights so they are adding new props for auto-flipping padding. The problem is if you have something called left or right which does NOT auto-flip, people will use it, and then be broken in RTL. I'd almost be inclined to have foo-left, foo-right which flip and then _if there's a use-case_ foo-left-in-all-text-directions and foo-right-in-all-text-directions which don't flip. But I don't know much about it, honestly. However it works, the obvious, default thing app developers will do probably ought to work by default in RTL. I kind of suspect padding-left and padding-right are the obvious default thing app devs will use. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Wed, Sep 1, 2010 at 2:52 PM, Havoc Pennington h...@pobox.com wrote: Hi, On Wed, Sep 1, 2010 at 2:03 PM, Shaun McCance sha...@gnome.org wrote: Well, all of the packing functions use start and end, but I guess that's just to make the term orientation-neutral. Looking through the docs, I do see properties like left-attach, left-margin, and left-padding. So it doesn't make sense to use start and end unless we switch all terminology. That's probably just pointless API churn. Side note: browsers are starting to provide properties using start and end: http://help.dottoro.com/lcedmdkb.php Well, what does GtkAlignment do already with its padding? I think the question is, does GTK just flip left and right, or does GTK let you choose to force left/right regardless of text direction and then also let you virtualize with start/end. I'd guess the browsers are not comfortable / unable to just flip all lefts and rights so they are adding new props for auto-flipping padding. The problem is if you have something called left or right which does NOT auto-flip, people will use it, and then be broken in RTL. I'd almost be inclined to have foo-left, foo-right which flip and then _if there's a use-case_ foo-left-in-all-text-directions and foo-right-in-all-text-directions which don't flip. But I don't know much about it, honestly. However it works, the obvious, default thing app developers will do probably ought to work by default in RTL. I kind of suspect padding-left and padding-right are the obvious default thing app devs will use. Right. We generally don't have a choice between follow-text-direction and hardcoded-left, anywhere currently. We just 'flip where it makes sense'. And that works okayish. Except for a few things where it really depends on the context. E.g you can have an GTK_ARROW_LEFT arrow that says: The beginning of the paragraph is there... or you can have have one that says please turn your head left. For the first one, you want flipping, for second one, you don't, since even in RTL-locales, left is still left... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On 08/30/2010 01:02 AM, Havoc Pennington wrote: In brief it adds to GtkWidget: h-align, v-align = FILL, CENTER, START, END padding-left,padding-right,padding-top, padding-bottom = int16 A small point to keep in mind when implementing something like that is the scrollbar behaviour, which is currently quite hard to get right. Basically, in editors like gedit or others, whose content can be scrolled, you usually end up with a scrollable area on the right of the window. When the said window is not maximized, the scrollbar is often not on the edge of the window, because it can be in a notebook for instance (as it is the case in gedit) or have margins, but when the window is maximized, it needs to be on the edge so one can benefit from Fitt's law for scrolling: moving one's mouse to the far end of the screen and use the wheel. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Mon, Aug 30, 2010 at 4:22 AM, Steve Frécinaux nudr...@gmail.com wrote: When the said window is not maximized, the scrollbar is often not on the edge of the window, because it can be in a notebook for instance (as it is the case in gedit) or have margins, but when the window is maximized, it needs to be on the edge so one can benefit from Fitt's law for scrolling: moving one's mouse to the far end of the screen and use the wheel. Are you suggesting some sort of automatically collapse padding when on a Fitt's edge feature? Or even better, make the padding clickable in that kind of situation? That would be easier if centralizing padding a bit I guess. Another thing your mail made me realize, by moving padding into widgets such as Button the padding area could become clickable (I guess in some of the implementation schemes I mentioned, the input-only window would probably end up not including padding, but in others it could). I don't know if padding should be clickable - or only clickable if it's between the widget and a Fitt's edge? If adding a nicer, more automatic way for no-window widgets to get events (as part of dropping GdkWindow), one possible elaboration would be to be smart about whether events on padding go to widgets, possibly including a rule that the widget only gets padding events if the padding is against a Fitt's edge. These features all seem like elaborations of padding cleanup but I do think a padding cleanup (and having padding generally be part of clickable widgets, not part of the layout container) would help do a nice Fitt's law feature. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Sun, Aug 29, 2010 at 7:02 PM, Havoc Pennington h...@pobox.com wrote: 2. supporting superclasses deriving from GtkWidget that want to add more padding area stuff to their subclasses on top of what GtkWidget already does. GtkMisc would be an example - maybe the only example? I forgot about Container::border-width which is another example of this. It might have the same two possible solutions: virtualize add/remove padding (cleaning up subclasses in the process) and make border-width additive with Widget padding, or just make border-width set the new widget padding props. In either case when porting Container subclasses, all border-width knowledge could be deleted from the subclass. border-width of course is yet another redundant padding API that could be deprecated. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Looking at ClutterBoxLayout, they separate x and y fill, which may be
worth adding here.
void clutter_box_layout_pack
(ClutterBoxLayout*layout,
ClutterActor*actor,
gboolean
expand,
gboolean
x_fill,
gboolean
y_fill,
ClutterBoxAlignment x_align,
ClutterBoxAlignment y_align);
This function has the same too many bools and ints problem as
gtk_box_pack_start though (always have to look up the order when
reading/writing code, no compiler warning on mixing them up), and has
fill and align as separate dimensions, so I'd like to fix those issues
with a nice enum.
In my patch this would probably become:
typedef enum
{
GTK_ALIGN_FILL_HORIZONTAL,
GTK_ALIGN_FILL_VERTICAL,
GTK_ALIGN_FILL, /* or FILL_BOTH? */
GTK_ALIGN_START,
GTK_ALIGN_END,
GTK_ALIGN_CENTER
} GtkAlign;
So that would add another nice handy feature that's annoying to do
with GtkBox right now - you could eliminate the need for a
GtkAlignment to keep a widget from expanding perpendicular to box
orientation.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On 08/29/10 19:02, Havoc Pennington wrote: - is it called padding or border (border is nice perhaps since it contrasts with all the existing stuff called padding) Why not copy the CSS box model to the extent that it's relevant? behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Mon, Aug 30, 2010 at 1:26 PM, Behdad Esfahbod beh...@behdad.org wrote: On 08/29/10 19:02, Havoc Pennington wrote: - is it called padding or border (border is nice perhaps since it contrasts with all the existing stuff called padding) Why not copy the CSS box model to the extent that it's relevant? Yeah (that's why I called it padding). I was just thinking it might be less confusing if this was border and all the deprecated stuff was padding. Or I guess this could match CSS and call it border and not include the background. Should probably first decide if whatever-it-is should include the background or not. Well, first decide if we want it at all ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On 08/30/10 14:01, Havoc Pennington wrote: Hi, On Mon, Aug 30, 2010 at 1:26 PM, Behdad Esfahbod beh...@behdad.org wrote: On 08/29/10 19:02, Havoc Pennington wrote: - is it called padding or border (border is nice perhaps since it contrasts with all the existing stuff called padding) Why not copy the CSS box model to the extent that it's relevant? Yeah (that's why I called it padding). I was just thinking it might be less confusing if this was border and all the deprecated stuff was padding. Or I guess this could match CSS and call it border and not include the background. Should probably first decide if whatever-it-is should include the background or not. Well, first decide if we want it at all ;-) Well, I was implicitly suggesting that we take all of CSS margin, border, padding and then some. behdad Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Mon, Aug 30, 2010 at 5:00 PM, Behdad Esfahbod beh...@behdad.org wrote: Well, I was implicitly suggesting that we take all of CSS margin, border, padding and then some. I see. Yeah, that could be cool. I thought about it a little but you have to figure out what background and border color mean in a GTK context; is there a way to set them? do widgets paint them or are they auto-painted before widget_draw() is invoked? Are they set by apps or by themes or both? In my sketchy patch the padding is the part inside the widget that has the widget's background, so it does leave room to add border and margin and the result would be CSS-alike. While if you renamed padding to border in this patch you'd be locked in to a non-CSS-like naming. I think it'd be fairly logical to first mop up padding (as in this patch) and then do follow-on patches to add border color (border pattern?), border, and margin. The border and margin patches would need the same add extra space in superclass mechanisms I was talking about here, but they'd also add the need for a paint edges in superclass mechanism of some kind. I guess even padding creates a painting question for any children with a non-transparent background that would logically extend into the padding - are there examples? I haven't looked at the new CSS-like styling mechanism at all so I don't know how that would interact. I do think padding can be cleaned up without having to solve all this (but maybe solving border and margin is pretty easy, I just haven't investigated) Should also seriously think through the use cases for CSS border and margin. Padding is widely used (via the various ways to set it in GTK), but there's no current way to do CSS-like border or margin, and I at least haven't seen people clamoring to be able to make colored borders or add transparent margins outside those colored borders. Of course in a canvas-like/HTML-like completely custom UI, i.e. nonstandard widgets that ignore the theme, it makes more sense. Another possibility is that CSS-like border should be something themes can set, if it'd be useful there. I don't know. it's a lot of additional questions and new use-cases, while padding is more of a cleanup. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
padding cleanup
Hi, Matthias's mention of padding props got me thinking about how this could be mopped up (based shamelessly on what we did in HippoCanvas and then BigBox) I'm attaching a patch that I haven't even tried to compile (my jhbuild setup is kinda hosed, don't ask) illustrating what I might like to see if starting from scratch. In brief it adds to GtkWidget: h-align, v-align = FILL, CENTER, START, END padding-left,padding-right,padding-top, padding-bottom = int16 Here are some opinions about the current APIs: * GtkBox would not need fill or padding flags on children if GtkWidget just had those built-in * GtkTable would not need fill or x/y padding either * fill and padding are universally useful child properties, not specific to any layout manager, so should be on Widget * xalign, yalign as floats are near-useless; 0.0, 0.5, and 1.0 cover 99.9% of cases * xscale, yscale as floats are also near-useless; 0.0, 1.0 cover 99.9% * xpad, ypad are annoying because you have to set two sides at once * having to create a GtkAlignment and pack a widget in it is clunky, vs. just setting a property * GtkAlignment-wrapping is sort of a clunky model for a UI builder, vs. setting props * GtkAlignment is generally redundant with at least some of the properties on the layout container it's inside * the way GtkMisc works is clunky (subclass has to do all the work), no methods on parent add stuff outside my main content to request or subtract stuff outside my main content from request * same clunkiness leads to wonky get_child_padding_delta() hack in GtkBin * often one wishes a widget was a GtkMisc and it isn't. * containers can't be a GtkMisc. * GtkMisc and GtkAlignment should have the same props, but they don't. xypad vs. leftrighttopbottom-padding is odd and illogical * redundant padding props make a mess of code where you are looking at some whitespace and part of it is in one spot and part in another (e.g. set xpad on a label, then pack the label into a box with padding) * fill mode should be mutually exclusive with center/start/end alignment, rather than an orthogonal setting So I'd love to see 4.x remove: GtkMisc, GtkAlignment, fill/padding props in all layout containers. In 3.x it'd be nice if all the random pads and aligns and scales were consolidated in GtkWidget so people could start ignoring the cruft. Two judgment calls / discussion areas I can think of. 1. if just taking a patch like the attached, which adds GtkMisc-style stuff to GtkWidget, all subclasses of GtkWidget would have to be modified to use the new add padding stuff to my request and remove padding stuff from my allocation calls. Hopefully this is not a necessary tedium - some way to make porting widgets easy, or unnecessary, would be better. - one approach: put padding stuff in the size_request / size_allocate *wrappers* in the same way that size groups and set_size_request are handled. all widgets just work without modifications, is the big plus of this. - another approach: somehow add a separate set of size request and size allocate methods that requested/allocated the inside-padding area instead of the including-padding area. Then GtkWidget would default-implement the current size request and size allocate by invoking the inside-padding versions, if present. The separate set of methods could be: . add a new interface, like GtkSizeRequest but with allocate also, and GtkWidget's default implementations do GTK_IS_THIS_NEW_INTERFACE() . add new virtual methods in GtkWidgetClass and check != NULL In this approach, to port a widget you'd just change its request/allocate implementations over to override different (but identical-parameters) superclass methods. - yet another approach: add a set of convenience functions that take the old-style functions as argument, so your get_width() implementation would call: return gtk_widget_get_width_with_padding(widget, real_get_width_func); where real_get_width_func would be the previous, old-style get_width(). eh. - final approach is punt, just require using the protected APIs like gtk_widget_get_padded_width() in the attached patch, which is still nicer than subclassing GtkMisc where you have to manually compute align and pad. But it's the same basic idea as how you subclass GtkMisc. 2. supporting superclasses deriving from GtkWidget that want to add more padding area stuff to their subclasses on top of what GtkWidget already does. GtkMisc would be an example - maybe the only example? I'm not sure if this is useful, but to make implementation of GtkMisc cleaner, one could remove knowledge of GtkMisc from its subclasses, and make GtkMisc padding/alignment additive with the built-in-to-Widget ones. So if you set both GtkMisc xpad and GtkWidget padding-left the sum of the two would be used. - one approach: virtualize add padding stuff to my request and remove padding stuff from my allocation calls. GtkMisc overrides these, chains up to GtkWidget, then adds its own stuff. GtkLabel now just
