Re: Themes [was: Unidentified subject!]

[raster redhat com]

On 28 Jan, Owen Taylor shouted:
->  
->  raster@redhat.com writes:
->  
->  > To make the themes discussion at least constructive, I have put up a
->  > web page detailing what at least I would call stage 1 of themes -
->  > probably the easiest to implement, with the most effect. This is
->  > intended to foster construcive discussion, not promote flame wars on
->  > themes. This is a start. please take alook at:
->  > 
->  > http://www.labs.redhat.com/themes.shtml
->  
->  (Why does Netscape insist on using a 8 point font when font
->  face is specified...)
->  
->  - 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?

->  - 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.

Can you think of a way arpund this but still allow the same effect?

->    Also, that could have the typical background pixmap disadvantage that
->    if the window is resized bigger, the user will briefly see then
->    widgets tiled into the newly larger windows. (Because X tiles
->    when the background pixmap is larger than the window, for
->    people who aren't familiar with the effect) I suppose the
->    answer to that would be to set the new pixmaps _before_ resizing
->    the window in the size_allocate function for each widget.

But currently you see a brief blanking of areas - which is a similar
effect. I perosnally see that as a moot point. - and yes.. my code
normally does:

scale_image();
free_previous_pixmap();
setbg_pixmap();
resize();
clear_window();

->  - What's "Shaping Method" in the last example?

It's just on or off - if on it can optionally specify a color to be
transparent if the image format doesn't have it. In the last example
its OFF.

->  (Note that GTK just specifies the fg and background colors for
->   a style and constructs the shadow colors from that.)

True.. but the data structs contain gc's for them all. i was being a
little more explicit for themes.

->  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.

->  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.

->  None of this is meant to be flammage. Just questions that came
->  into my mind while looking the stuff over.
->  
->  Regards,
->                                          Owen
->  
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/