Subject: Colorset for Title bar's

From: Olivier Chapuis <[email-masked]>
Date: Sat, 16 Nov 2002 10:22:53 +0100

Hello,

I would like to implement Colorset in title bar's. I would
like to implement MultiColorset too.

Is this reasonable:

Add:
	
	Colorset cset [alpha]

to the {Add}TitleStyle, {Add}ButtonStyle and BorderStyle
command. These commands will apply the colorset cset background
on the Title bar, button bar and border with the given alpha.

Add:

	MultiColorset \
		Main cset [alpha] \
		LeftMain cset [alha]
		... etc ... as MultiPixmap

to TitleStyle.

Any comments?

Olivier
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 16 Nov 2002 13:42:12 +0000

> 		... etc ... as MultiPixmap

I did not immediatelly understand what alpha is good for. But I think I
understand it. Any new Add*Style adds a colorset layer.

The initial starting background may be a solid bg from "Style Colorset".
But this is not very good for defining transparent titles/buttons/borders.
I think it is acceptable, instead, to say that the first colorset should
be fully destructive, i.e. its alpha is discarded.

Similarly MultiColorset may be destructive, i.e. no alpha in the mandatory
Main/LeftMain/RightMain. Other MultiColorset parts may have alpha relative
to Main. There are also stretch arguments.

MultiPixmap may be removed in favor of MultiColorset if this simplifies
the code (I think, yes).

Seems good for me, one should just distinguish between internal alphas in
the colorset definition and the external alpha in the colorset usage.

We probably should add different settings for different windows later.
Similarly to FocusStyle. I.e.: [Add]TitleStyle XTerm <current_parameters>.
Then we may remove decors. But this is really not for now.

As for BorderStyle, I think it is not very simple if you want to get nice
results. It may have MultiColorset too with different colorsets for corner
(to be mirrored) and horizontal and/or vertical parts (to be mirrored and
tiled). This may wait.

Seems a lot of work. Good luck. :)

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 17 Nov 2002 10:15:36 +0100

> But this is not very good for defining transparent titles/buttons/borders.

Why? Any way Transparent will be not supported for title bar's.
RootTransprent will work.

Colorset 1 bg blue, fg white, RootTransparent
Style * Colorset 1
TitleStyle Inactive Colorset 1 30

will give a blue inactive title bar "textured" with the root background.

Colorset 1 bg blue, fg white, RootTransparent
Style * Colorset 1
TitleStyle Inactive Colorset 1

will give a root transparent title bar.

> be fully destructive, i.e. its alpha is discarded.

I think that this will add unnecessary complication in the code.
Moreover these "Style Colorset" (and "Style Color") will be used
for the fg/text and relief. This is a bit problematic ...

> to Main. There are also stretch arguments.

In fact I do not see why we should have any mandatory "type" in the
Multi* option. We have a solid "common" bg from "Style Colorset" and we
draw over it. I will see.

Yes, stretching maybe problematic. For example "LeftText a_grad_cs".
Maybe I will add a "width" argument (e.g., 20p). Also, maybe,
we can add XPixmap and YPixmap Colorset option.

> MultiPixmap may be removed in favor of MultiColorset if this simplifies

I do not know, maybe the two code can be merged.

Suzanne any opinion?

Any way I will first implement Colorset and the MultiPixmap code will
help a lot for MultiColorset.
 
> Then we may remove decors. But this is really not for now.

Maybe this is not so difficult. But what do you do with a window
named Inactive ?
 
> (to be mirrored) and horizontal and/or vertical parts (to be mirrored and
 
Yes why not. Note that there are no AddBorderStyle cmd so no alpha
here.

> Seems a lot of work. Good luck. :)

Maybe not so lot of work. At least for TitleStyle and ButtonStyle
Colorset. Updating the Colorset and the RootColorset may lead to some
complication (do not know yet).  The borders code is really clean :o)

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 17 Nov 2002 14:56:16 +0100

> Yes why not. Note that there are no AddBorderStyle cmd so no alpha

No, first the "Style BorderColorset" should be applied and then the
BorderStyle Colorset should be applied with a possible alpha.

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 17 Nov 2002 14:32:01 +0000

> Why? Any way Transparent will be not supported for title bar's.

I thought Transparent may be supported too. If only RootTransparent is
supported, it's not very important whether to have a solid bg base or not.

> for the fg/text and relief. This is a bit problematic ...

It is not very clean that both "Style Colorset" and TitleStyle colorsets
are used (and different colorset properties are ignored). On the other
hand maybe having an external base simplifies TitleStyle, I don't know.

> draw over it. I will see.

The problem is that the solid bg base is almost never useful for titlebars
designed using MultiPixmap. Instead, having the Main colorset as the base
for all other parts may be very useful.

I think we agree that the resulting TitleStyle has only one optional
MultiColorset, but several optional Colorset-s, so in AddTitleStyle
MultiColorset and Colorset work differently.

> we can add XPixmap and YPixmap Colorset option.

I think we need to rotate a colorset when different titlebar positions are
used (depending on one or another TitleRotatedCW options). So XPixmap and
YPixmap (if I understand them correctly) are not needed, at least now.

I also don't leave the idea to call all "Pixmap" in the user configuration
"Image" one day. :)

> Maybe this is not so difficult. But what do you do with a window

I would not discuss now backward compatibility issues. But if TitleStyle
is physically (not nessesarily using the syntax) moved to window's Style,
the main non conflicting syntax should be TitleStyle * Inactive <params>.
I don't think this is needed for 2.6, but we will see.

> complication (do not know yet).  The borders code is really clean :o)

TitleStyle/ButtonStyle/BorderStyle were always considered difficult to be
converted to colorsets. If it is not difficult for you, fine. :)

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 18 Nov 2002 10:40:55 +0100

> 		... etc ... as MultiPixmap

Well, I won't stop you doing it, but are you all aware that the
whole code is going to be thrown away, probably next year?  As I
said before, I think no new functionality should be added to the
{Button,Title,Border}Stlye commands anymore.  My estimation is
that at least 50% of the code doing this will be just thrown away
and on the other hand makes the big decoration rewrite much more
complicated.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 18 Nov 2002 22:14:05 +0100

> and on the other hand makes the big decoration rewrite much more

:o)

I do not want to wait 3 years or more before to see colorset in
TitleStyle for a stable release. I do not believe on estimation about
fvwm code, I believe on written code (or on code that are going to be
written). At least 3 times "conditional style" stop me to implement
some stuff. Now I see that conditional style will not be in 2.6 (fine)
and that we do not have even style by Id (which is IMO a must for
2.6).

Moreover, I do not see the problem with the {Button,Title,Border}Style
commands. There are dramatically powerful (yes there are some odd
things, there are missing feature and yes I will add maybe some). The
only real pb I see is that they are not fvwm Style and this pbs is not
really a drawing pbs.

BTW, here my 2.6 todo list (optimistic).

- Colorset in {Button,Title,Border}Style
- A type of "gettext" support in config file
- Better key/mouse binding in the Pager
- minimal randr support (XFree-4.3 will have a functional randr for
resizing and rotation)
- Style by Id (maybe Dominik)
- Icon background (maybe Dominik)
- bug fix, testing, bug fix, testing, bug fix ........

I've no 3.0 todo list. I will begin to think to 3.0 when 2.6.?
will be released :o) 

Olivier

---

From: Suzanne Skinner <[email-masked]>
Date: Mon, 18 Nov 2002 20:56:45 -0500

> I do not know, maybe the two code can be merged.

I'm all for it. I don't think MultiPixmap does anything that couldn't be done
with properly applied multiple colorsets, and MultiColorset would probably do
more (e.g. transparency).

Suzanne

-- 
[email-masked] - http://www.igs.net/~tril/

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.
                                    -- Principia Discordia
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Nov 2002 11:40:07 +0100

On Mon, Nov 18, 2002 at 10:14:05PM +0100, Olivier Chapuis wrote:
> TitleStyle for a stable release.

We already have a Colorset and a HilightColorset style.  I won't
say anything against using more parts of the colour set in the
window decorations.  But why does it have to be in the BuggyStyle
commands?

> I do not believe on estimation about

Well, if we don't stop adding things, we won't have 2.6 anytime
soon.  Remember that 2.6 was planned as a quick follow-up to 2.4
to add some nifty functionality before the big clean up.

> things, there are missing feature and yes I will add maybe some).

They are also horribly inflexible (all configs are global), buggy
(leaking memory) and unintuitive (*weird* syntax).

> The

Wow!  I already mentioned that I want to put 2.6 into feature
freeze no later than 31st of December, did I?

My list looks like this:

 - Clean up tear-off menus (a huge task)
 - bug fix, testing, bug fix, testing, bug fix ........

In my eyes, adding the "Style by Id" thing would delay the next
stable release by at least a year.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 20 Nov 2002 17:13:46 +0100

> window decorations.  But why does it have to be in the BuggyStyle

Because replacement for {Button,Title,Border}Stlye commands will lead
to interminable discussion which will end after the feature freeze.
I think this is in the 3.0 todo. Moreover, {Button,Title,Border}Style
are widely used

BTW, there is this in the man page:

	This command is deprecated and will be  removed  in
        the  future.

in the top of the {Button,Title,Border}Style commands. It seems
to me that "deprecated" means that these commands should not be
used. No? If yes which commands can do the same job?

> to add some nifty functionality before the big clean up.

I was not award of this. They were very few discussion on the goal
of 2.6.

> (leaking memory) and unintuitive (*weird* syntax).

I will try to fix the memory leak during the freeze.

> freeze no later than 31st of December, did I?

Yes, I know. I think it is a very good date. Maybe the feature
freeze for modules can be delayed a bit. As I say this list
is optimistic. I will have to make some choice.
 
> stable release by at least a year.

Or you sure that this will be so difficult. I do not ask for
conditional style.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 20 Nov 2002 18:08:44 +0100

> used. No? If yes which commands can do the same job?

Style * HilightColorset

Okay, that won't give us the MultiColorset things, but I don't
think they are this important for 2.6.  The advantage is that we
can keep the code unmodified in 3.0.

[snip]

> I was not aware of this. They were very few discussion on the goal
> of 2.6.

Well, I know most of the time it is that I just make the
decisions, chiefly because we lose interest in the discussions and
nobody cares too much about the outcome.  But I really think it
would be good to communicate more about strategy.  We (you, me and
Mikhael) seem to have orthogonal goals in many aspects.

> I will try to fix the memory leak during the freeze.

I hope you know what you're doing ;-)  Good luck.

> is optimistic. I will have to make some choice.

Okay.

> Or you sure that this will be so difficult. I do not ask for

Yes, absolutely sure.  It is very disruptive and requires a full
fledged rewrite of the style code - unless we hack up some
temporary syntax that is dumped in 3.0.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 22 Nov 2002 08:27:17 +0100

> can keep the code unmodified in 3.0.

You lost other features vs the {Toggeled}{Active,Inactive}{Up,Down}
state and Buttons "bg". (Also you will be not able to get a gradient
textured with the root background :o)

An other risk is that user will style use {Button,Title,Border}Style
and do not switch to Colorset config (MultiPixmap).  On the other
hand, I am agree that using Style {Hilight}{Border}Colorset have some
advantages.  At present time I've implemented Colorset title bar's with
{Button,Title,Border}Style. I may change this. 

Mikhael an opinion?

One point is:

TitleStyle blabla Colorset 2
ButtonStyle all blabla -- UseTitleStyle

Colorset 2 a Hgradient

if we follow the current TitleStyle heuristic this is equivalent to

TitleStyle blabla Colorset 2
ButtonStyle blabla Colorset 2

which is totally stupid. What I've done is with

TitleStyle blabla Colorset 2
ButtonStyle all blabla -- UseTitleStyle

the gradient is applied/computed to/for the full window bar
(title & buttons).

Similary with

BorderStyle blabla Colorset 2
TitleStyle blabla -- UseBorderStyle
ButtonStyle all blabla -- UseBorderStyle

the gradient is applied/computed to/for the full window frame.
Moreover, 

BorderStyle blabla Colorset 2

is, in any case, applied/computed to/for the full window frame.
IMO this is the resonable way to set the border with a colorset.

So, {Hilight}{Border}Colorset will be more natural but will
depends on some {Button,Title,Border}Style ...

> would be good to communicate more about strategy.

Agree. I think I/we have time problems. 3.0 will be a good
occasion.

> We (you, me and

And IMO this is not a bad thing.

> temporary syntax that is dumped in 3.0.

Really, I will be very very happy to see Style by Id in 2.6.
I vote fort he "temporary syntax", but you decide on this
point.

Olivier