plib-users

Re: [Plib-users] Translucent Widgets

[dave <da...@mi...>]

I'd like to have various groups of widgets that have differing states of 
translucence. It isnt obvious to me how to do this. I don't know much 
about openGL/Glut, after all, the motivation to use higher level 
libraries is partly so I dont have to learn as much low-level details.

It seems to me that setting up a blend function just before calling 
puDisplay is the wrong approach. Setting the defaultColour would apply 
to the entire PUI display list would it not?  Also, it seems like one 
would always want to save/restore the previous defaultColour as well, 
and this would be going on a lot.


I suspect it is better to derive new translucent PUI classes and put the 
blending within each widget. One could then get a group box where the 
box's background is in one state of translucence, and the widgets on top 
of it can be slightly less translucent, ie, more solid, depending on how 
one programs the widgets as one builds the group.

It seems to me that each object should have a setColour() and load 
color, ie, that these functions should be within the puObject class 
instead of being global to PUI.

This seems like excessive work so I must be wrong, I just dont know 
quite how. Any suggestions?

Re: [Plib-users] Translucent Widgets

[Sebastian U. <ud...@ha...>]

On Thu, 17 Jan 2002, da...@mi... (dave) wrote:
> Date: Thu, 17 Jan 2002 16:05:55 -0600
> To: ud...@ha...
> From: da...@mi... (dave)
> Subject: Re: [Plib-users] Translucent Widgets
> 
> It calls:
> 	static void load_colour_scheme()  within puObject.cxx.
> 
> Maybe my C++ is a bit weak. There isn't a scope resolver. Isn't it true 
> that just because  it's in the puObject.cxx file doesn't necessarily 
> mean its part of the class?  Maybe I'm wrong. but my thought was to be 
> part of the class it would need to be:
> 
>          static void puObject::load_colour_scheme()
> 
> wouldnt it?
> 
> C++ has evolved a bit since I last used it. Could it be that the scope 
> resolver is implicit to the entire cxx file?

Yes. It was all the time.

The

void load_colour_scheme ( float col[][4], float r, float g, float b, float
a ) ;

routine does nothing but filling the colour table specified with the
calculated values.


Hence, it can be and is used by both

puSetDefaultColourScheme

which modifies PUI's _global_ colour table specifying the default colours
that are used when a widget is created and

puObject::setColourScheme

which modifies the widget's _local_ (!) colour table.


- Sebastian

Re: [Plib-users] Translucent Widgets

[dave <da...@mi...>]

Sebastian,

Well that answers that one.
Yes,while you were answering I figured out that I had confused
puSetDefaultColourScheme with puObject::setColourScheme.


I am still pondering the subject of whats going on inside widgets with 
"styles" though as far as blending goes. Hopefully a blend just affects 
them all equally once a puObject::setColour is done,  and all is well.
I don't know whether one would ever want the pieces implied by a style 
(foreground,background,mid.lo,hi,etc) to be affected uniquely though, or 
if it would even be possible.

Thanks for the feedback.
-Dave




Sebastian Ude wrote:

> 
> On Thu, 17 Jan 2002, da...@mi... (dave) wrote:
> 
>>Date: Thu, 17 Jan 2002 16:05:55 -0600
>>To: ud...@ha...
>>From: da...@mi... (dave)
>>Subject: Re: [Plib-users] Translucent Widgets
>>
>>It calls:
>>	static void load_colour_scheme()  within puObject.cxx.
>>
>>Maybe my C++ is a bit weak. There isn't a scope resolver. Isn't it true 
>>that just because  it's in the puObject.cxx file doesn't necessarily 
>>mean its part of the class?  Maybe I'm wrong. but my thought was to be 
>>part of the class it would need to be:
>>
>>         static void puObject::load_colour_scheme()
>>
>>wouldnt it?
>>
>>C++ has evolved a bit since I last used it. Could it be that the scope 
>>resolver is implicit to the entire cxx file?
>>
> 
> Yes. It was all the time.
> 
> The
> 
> void load_colour_scheme ( float col[][4], float r, float g, float b, float
> a ) ;
> 
> routine does nothing but filling the colour table specified with the
> calculated values.
> 
> 
> Hence, it can be and is used by both
> 
> puSetDefaultColourScheme
> 
> which modifies PUI's _global_ colour table specifying the default colours
> that are used when a widget is created and
> 
> puObject::setColourScheme
> 
> which modifies the widget's _local_ (!) colour table.
> 
> 
> - Sebastian
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 
> 
> 
> 

Re: [Plib-users] Translucent Widgets

[Sebastian U. <ud...@ha...>]

On Thu, 17 Jan 2002, da...@mi... (dave) wrote:
> Date: Thu, 17 Jan 2002 15:28:37 -0600
> To: pli...@li...
> From: da...@mi... (dave)
> Subject: Re: [Plib-users] Translucent Widgets

[...]

> It seems to me that each object should have a setColour() and load 
> color, ie, that these functions should be within the puObject class 
> instead of being global to PUI.

What about:

void puObject::setColourScheme ( float r, float g, float b, float a = 1.0f
) ;
void puObject::setColour ( int which, float r, float g, float b, float a =
1.0f ) ;

?


- Sebastian

Re: [Plib-users] Translucent Widgets

[Steve B. <sjb...@ai...>]

dave wrote:

> I'd like to have various groups of widgets that have differing states of
> translucence. It isnt obvious to me how to do this. I don't know much
> about openGL/Glut, after all, the motivation to use higher level
> libraries is partly so I dont have to learn as much low-level details.
> 
> It seems to me that setting up a blend function just before calling
> puDisplay is the wrong approach. Setting the defaultColour would apply
> to the entire PUI display list would it not?  Also, it seems like one
> would always want to save/restore the previous defaultColour as well,
> and this would be going on a lot.

There are really only two mechanisms - set the default colour - or set
the colour of each widget individually.

> I suspect it is better to derive new translucent PUI classes and put the
> blending within each widget. One could then get a group box where the
> box's background is in one state of translucence, and the widgets on top
> of it can be slightly less translucent, ie, more solid, depending on how
> one programs the widgets as one builds the group.

That tends to happen that way anyway because if you (say) set the default
alpha to 0.5 then the group box obscures 50% of the light coming from
behind it and adds in 50% of it's own colour.  Then when you render
a button or something on top of that, you get 50% of the light from
behind it and 50% of the button colour.  In total, you get 25% of the
ultimate background and 25% of the group box plus 50% of the button.

Presuming you choose reasonably harmonious colours for group box and
button, the button will *look* more opaque than the rest of the box
simply because less of the background is showing through.
 
> It seems to me that each object should have a setColour() and load
> color, ie, that these functions should be within the puObject class
> instead of being global to PUI.

They are within the puObject class.
 
Every widget is derived from puObject - and puObject has member functions:

  setColour ( which, r, g, b, a ) ;

...where 'which' can be:

 PUCOL_FOREGROUND
 PUCOL_BACKGROUND
 PUCOL_HIGHLIGHT
 PUCOL_LABEL
 PUCOL_LEGEND
 PUCOL_MISC

This gives you minute control over every single stoopid little part of
every single silly little widget...if you have the patience to choose
them all!

...or you can use:

  setColourScheme ( r, g, b, a ) ;

...where you pick the overall colour and the package 'tastefully' chooses
foregrounds and backgrounds that look good. (Usually!)

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net