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

List:       gtk-app-devel
Subject:    Re: GtkProgressBar colors: Help with this FAQ
From:       John K Luebs <jkluebs () luebsphoto ! com>
Date:       2004-11-29 7:12:31
Message-ID: 20041129071231.GA14628 () luebsphoto ! com
[Download RAW message or body]

On Wed, Nov 24, 2004 at 12:43:01PM -0600, Eckhoff, Michael A wrote:
> In gtk/gtkprogressbar.h one can find four functions 
> of the "gtk_progress_bar_set_" variety, none of which address the widget's
> use of color. Nor do the properties in GtkProgressBar deal with color.
Well, of course, as this would not follow with the general design of GTK.

> It has been suggested that one can color the indicator bar using
> gtk_widget_modify_bg(GtkWidget* pbar, GTK_STATE_PRELIGHT, GdkColor* color);
>  
> while the color of the well can be changed with
> gtk_widget_modify_bg(GtkWidget* pbar, GTK_STATE_NORMAL, GdkColor* color);
>
These are not mere suggestions, but are the definitive way for setting
the colors to paint the details of the progress bar widget. 
> But these calls do not always work. Several respondents state that the
> problem
> stems from certain "engine themes" (like bluecurve).
As far as the engine is concerned, it isn't a problem, it's just doing
what it's supposed to do. Although the above functions set/override
the style colors for the widget, their actual use is at the discretion
of the engine, since that is what defines the actual widget drawing
code.
> 
> Question 1: Can somebody explain this in more detail? In particular, how do
> you "disable a theme", and what are the dangers when porting to another 
> machine?
I think you mean engine. A theme consists of a style definition in an rc
file, any number of supporting graphics files for textures/skinning, and
dependencies on a number of engines. Most themes use only one engine
(like pixmap) but one could use a different engine for each class of
widget in the extreme.

Engine and widget styles are completely defined by the rc files that
are documented in the GTK documentation.
With an application specific rc file you can set the engine on each
individual widget or subtree of widgets in addition to all the style
properties and colors.

This issue of style has nothing to do with porting to other machines
(except insofar as individual engine portability, which is usually quite
good).

> Question 2: Can somebody offer a fix?
There is nothing to fix. The actual colors and appearance of the widgets
are completely determined by the engine used, and this is by design. If
you want to clearly define the colors, either use a known engine or the
default (builtin) engine.
You set the engine for widgets with a style definition in an rc file.

> Others have suggested using GtkRcStyle and rc files as outlined (briefly!)
This is not a suggestion. If you want to have fine grained control over
the widget appearance you will have to use the rc style system at some
point and either parse additional gtkrc files or parse from strings.

I think your best bet is to look at the "Resource Files" chapter in the
GTK+ Core Reference and to also take a look at the gtkrc files from some
of the most complex themes you can find. This should give you an idea of
how the rc style and engine system works.

In general, for desktop apps you do not want to use the color
modification or embedded style definitions in your code, as the point is
to allow the user to skin/theme the app to his liking. Obviously there
are exceptions, but I think it is usually best to keep things rc file
based as much as possible.

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