Re: Style and Spacing (and Themes, but only in the end)

["Juergen A. Erhard" <jae laden ilk de>]

>>>>> "Owen" == Owen Taylor <otaylor@gtk.org> writes:

[SNIP]

    >> It would be nice if one could begin to start handling this in such a
    >> way that it's easy later to implement.  Okay, maybe I just have to
    >> begin to replace all spacings with (hopefully) properly named
    >> constants.

    Owen> Compiled in constants are not the right way to go here.
    Owen> Spacings need to be adjustable under user control, at run time.

What I meant was, a) named constants are better than pure numbers (and
I don't use named constants now... shame on me) and b) choose those
names in a way so that (hopefully) the functions/names that will be
used for this later are the same (so, for example,
`COMPLEX_DIALOG_BORDER' just needs to be replaced with
`complex_dialog_border()').

    Owen> Here's some ideas that come to mind.

    Owen>  - Provide some conversion functions and macros:

    Owen>   gtk_container_set_border_width (container, D(0.3,CM));
    Owen>   gtk_widget_set_usize (widget, D(3,EM), -1);

    Owen> where D(0.3,CM) gets converted to

    Owen>  gtk_dimension(0.3, GTK_CM);

    Owen> or maybe directly to:

    Owen>  (0.3 * gtk_dimensions[GTK_CM])

    Owen> The problem is that D(3,EM) should be relative to
    style-> font, and that may not be decided until after the border
    Owen> width is set, and may be changed dynamically at run time.

I don't think this is the way... the only thing this will gain us
(even though this is a major benefit in and of itself), will be to
make layouts really font-dependent... but, as you mention, this is not
as simple as 1-2-3...

    Owen>  - Provide new variants for all functions taking dimensions
    Owen>    (There were about 20 last fall, probably more now),
    Owen>    that instead of an integer, take a float and a unit. (Or maybe
    Owen>    a string)

    Owen>    gtk_container_set_border_width_d (container, 0.3, GTK_CM);

    Owen>    gtk_container_set_border_width_ds (container, "0.3 cm");

    Owen> What units should be provided? Probably:

    Owen>  GTK_PIXELS, GTK_IN, GTK_CM, GTK_PAD (a unit of spacing from the style)
    Owen>  GTK_EM (The "em" of style->font). Maybe also a GTK_INVALID to
    Owen>  cover the cases where -1 is currently used as a flag.

Units: yes.  But additional functions: no.

    Owen>  - Make all dimensions signed and give special meanings to
    Owen>    certain negative values:

    Owen>    gtk_container_set_border_width (container, GTK_SMALL_PAD);

    Owen>    This doesn't work if the dimension actually could be negative,
    Owen>    or could inadvertantly become negative. It's not too flexible
    Owen>    either, though that could be a good thing - since it would
    Owen>    help ensure a consistent look and make it easier for the
    Owen>    user to adjust.

I think this'd be the way to go... come to think of it, why don't we
recycle (in a way) GTK's wonder `named signals' concept (okay, so it
was S&P's (P's mainly, I guess)), and make those dimensions strings?

So... that would be either

  gtk_container_set_border_width_s(container, "complex-dialog-border-width")

or

  gtk_container_set_border_width(container, gtk_dimension("complex-dialog-border-width"))

I think this latter variant would be less work, and cleaner... and
more flexible to boot.

After having sealed this envelope, I tore it up again: an even better
concept would be if there was a

  gtk_container_set_border_width_dynamic(container, "complex-dialog-border-width");

which directs the container to take its border from the (dynamic)
dimension named.  Now, things like GNOME have their standard names for
this, and a dialog for specifying those.  When the user changes one
such dimension, the dimension emits a "changed" signal that causes all
the UI elements that depend on this dimension to resize.

Would be quite a bit of work, of course... but ultimately `way cool',
I think.

What do you think?

    Owen> It is certainly something that needs to be addressed (I've felt
    Owen> that way ever since all the space was compressed out of the
    Owen> GIMP dialogs). If anybody has comments on the above ideas,
    Owen> or ideas of their own, I'd appreciate hearing them.

As I just mentioned, gtk_dimension(const gchar *dimension) would be
the kill-all, I think.  Needs some fleshing out, but I think that
could be almost entirely based on signals...

  gtk_dimension_new("NAME OF DIMENSION") would create an new dimension.

  gtk_dimension_find("NAME") would find one.


Still, how this should react to font sizes is not clear to me at the
moment.  Maybe dimensions are generally something like "3em" or
something, which the widget then translates to pixels via `[dimension
translateViaStyle:_style]' (I love ObjC ;-) And simple "3" is not `3
pixels' but `3 ex' vertically, and `3 em' horizontally (`3 pixels'
would be "3 px", similar to TeX... why not use TeX's units?).  That
would be necessary for nice gtk_container_set_border_width...


Anyway,

Bye, J

--
Jürgen A. Erhard  eMail: jae@laden.ilk.de  phone: (GERMANY) 0721 27326
	My WebHome: http://members.tripod.com/~Juergen_Erhard
	   GNUstep - Free OPENSTEP (http://www.gnustep.org)
	Win32 has many known work arounds. For example, Linux.