Re: Themes [was: Unidentified subject!]

[Owen Taylor <owt1 cornell edu>]

raster@redhat.com writes:

> On 28 Jan, Owen Taylor shouted:
> ->  
> ->  - I'm curious as to how the ScaleMethod works. It seems that
> ->    in many cases you don't just want to blow up the background.
> ->    (Maybe OK for most buttons, but would be pretty awful for
> ->    a Text widget, unless the central area was just a solid color) 
> ->    So, how are the edge regions handled for tiling? Is (say) the top
> ->    edge tiled horizontally?
> 
> ScaleMethod - in at least the plan there merely determines the size of
> the pixmap - that is just set to the background and tiled.. if the size
> is the same as the widget - the tiling is not apparent.
> 
> Is what you're getting at when you have a large expanse.. you might
> wish to use a pixmap to deinfe the borders (for lets say soft slightly
> rounded borders) but keep the center single-coloured or tiled? I see
> your point being - you'd have a pixmap the size of the whole text area
> just to decorate it - the middle parts being mainly one color. What you
> want is to split the pixmap into separate parts.. right? corners,
> edges, middle and define different properties for them?
> 
> This would solve that problem - but it would be rather more compilcated
> to write the code... Is this what your point was?

Yes, that was my point. For big expanses with borders, even if
you leave aside questions of storing the background pixmaps, if 
you want a tiled background for the center portion, then scaling
will probably give suboptimal results.

From the purely visual point of view, you could use the division
of the pixmap into regions you proposed, but simply tile everything
but the corners when they need to be expanded. (There is a question
of fitting the parts together - possibly a combination of scaling
within a small range and integer tiling would be needed)

I can see three basic ways to implement this

- Draw the whole thing onto one pixmap, and use it as a background
  for the window. A bit wasteful in server memory (since many
  portions are just tiled) and in speed (since the client has
  to do the tiling itself) but good appearance.

- Divide the window into nine subwindows, and set up a separate
  background on each. Subwindows may be cheap but 9x ?

- Set the middle portion as the window background. Then draw
  in the borders with XCopyArea. Least overhead in server
  memory, but could mean a lot of calls to draw the border.
  (This could be alleviated by forming long thin pre-tiled sections
  of the edge pixmaps, so that you would only need 8 calls
  to do the border - less than if you were drawing with bezels)

  This would require the most restructuring of GTK code (but
  still not that much). 

> ->  - Is the whole pixmap (borders and all) set as the background?
> ->    This would mean putting a lot of different big pixmaps onto the
> ->    server for each different size of widget. 
> 
> Yes. borders are part of the pixmap - but you can just tile one for
> "patterns" but to get a unique effect you would need to do this. Imlib
> handles naieve code and shares pixmap id's for the smae sized pixmap
> scaled from the same original image data.

Sharing pixmaps helps if you have lots of identically sized buttons
(gnomine?) I don't think this happens too much in general GTK
code though.
 
> Can you think of a way arpund this but still allow the same effect?

See above. Though none are completely satisfactory.

[ ... ]

> ->  The big question in my mind is how all of these attributes would be
> ->  specified for widgets. Note that for some widget types, several
> ->  pixmaps will have to be specified. So simply adding the attributes to
> ->  styles won't work. (unless we specify allow specifying styles for 
> ->  parts of widgets.
> 
> Hmm yes. I realise (for example - scrollbar - scollbar pixmap, arrow
> pixmaps (2), trought pixmaps - then differnt styles per state). I am
> "ignoring" that for now and just concentrating on the button - and take
> the same principals and expand them to to other widgets.

Its possible that decent results can be obtained by just setting
up themes for the easy widgets, and using a consitent bezel color/lighting
style for the rest. But I think the question of how to specify
more is worth actively considering. (So we don't have to break
everybodies themes when the rest is added).

> ->  Another question is whether alternate "standard" styles (Motif, W95,
> ->  etc.) can be specified efficiently enough with the themes mechanism
> ->  to jusitify dumping the currently non-functional style class mechanism
> ->  entirely? (Can people who want efficiency just live with the 
> ->  standard GTK look?)
> 
> No - because those themes are meostly replacements of the bevel drawing
> code (mostly) They can be specified, but will require pixmaps under the
> aobe scheme - I suppose there should be another attribute defining how
> to draw a bevel. I have never thought of this before myself, so input
> would be nice. I generalised on the pixmap being able to describe any
> bevel - maybe at the expense of memory. If we can have a bevel
> defintion that can define the current bevel style and include others -
> even beyond just motif/win95/next bevels - but a bit further, then this
> would be great - and most probably the only glaring hole I can see.

The original GTK code assumes that seperate bezel-drawing routines
will be written and linked in for each style. Which isn't too
conducive to post-hoc user modification.

Using pixmaps to do the borders in one of the modes outlined above
is probably the most general method. (Although it cannot be adopted
arbitrary shaded polygons as in gtk_draw_polygon). Another possibility
is to specify a sequence of intensity levels for the edges and
draw the bevels as lines using appropriate colors. My visual
memory for Win96 and Next looks isn't good enough to say if this
is sufficient.

(If the description isn't clear, I mean that GTK's current style
woudl be specified as something like:

OUT: topleft=[white light] bottomright=[dark black]
IN: topleft=[dark black] bottomright=[white light]

Very roughly... For Motif's 1-pixel style there would only be
one color specified for each edge)

(One tricky thing to think about is the "knob" in the center
of the Next scrollbars ... can that be handled without adding
a special "knob subwindow" onto every GTK scrollbar?)

                                        Owen