Subject: Colorset wish-list

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 3 Jan 2003 20:22:57 +0000

The current colorset functionality is simply amazing, but I feel that
something is not complete. I am trying to see what.

1) Colorsets in menus.

We still don't have full ActiveColorset support including images or
gradients. And it would be nice to support Transparent in it similarly to
FvwmIconMan and FvwmButtons. I.e. it is possible to get active item
background by just tinting the normal background (a part of a big image).

Greyed items in menus may support the same things using transparent or
even non transparent GreyedColorset. It is ok with me if the
compatibility is broken and it should be marked Transparent to have what
we currently have. Unless there are technical problems to achieve this.
BTW, GreyedColorset seems to be broken in cvs.

2) Colorsets in window decorations.

I see small advantages in how windows ignore most of the things defined in
Colorset/HighlighColorset and use TitleStyle Colorset as filters for
different title states. But I think it will not be very inconsistent to
fully apply Colorset/HighlighColorset (not just fg/bg) and start
TitleStyle Colorset from non plain colorset. This way some titlebar
designs would not need TitleStyle at all, this includes half of the
current fvwm-themes themes. Of course this is not trivial, since it
involves the issues like different states and UseTitleStyle, but I hope it
is solvable. I think it is good to support Colorset/HighlighColorset
fully. If we do this, Main from MultiPixmap probably may be removed as
redundant (and I don't worry that this means a design with MultiPixmap
can't be done without colorsets). I think it also may mean that it is
possible to use Transparent and not just RootTransparent in Style
Colorset, but this is not really important.

Similarly to BorderStyle vus BorderColorset.

3) Root Transparency.

It would be very useful to have the following functionality in fvwm-root
using "-d -r" or similar option. Read the current random root background,
(re)create an image from it and then retain it. I hope this does not sound
meaningless. This way anyone who wants to use RootTransparent should run
one command and it would work regardless of the current background.

4) In FvwmPager it would be nice to have {Hilight}TitleColorset, the
current plain rectangle taken from HilightColorset is really not enough.

5) Colorset HueRotation (recoloring). Should be more useful that Tint in
some situations. Would be nice to have.

I didn't try yet different combinations of Icon{Background,Title}Colorset,
but it looks very good with nice tile.

Regards,
Mikhael.
--
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: Olivier Chapuis <[email-masked]>
Date: Sat, 4 Jan 2003 10:34:43 +0100

> BTW, GreyedColorset seems to be broken in cvs.

I do not think this is difficult to implement. Only the fg colour
from the GreyedColorset is used for inactive items and the full
GreyedColorset is used for the active one.
 
> Similarly to BorderStyle vus BorderColorset.

For me all these are post 2.6.

> one command and it would work regardless of the current background.

This is not possible in general. Why not just use fvwm-root to set
the root window bg? We may add jpg (and svg) support in the future.

> current plain rectangle taken from HilightColorset is really not enough.

Yes, this will be good. I do not know if I will have the time to
implement this. My Pager plan is to add

WindowActionFixed (Mouse x) Action
    causes the pager to execute Action when you click on a
    mini-window and this click does not imply a desk or viewport
    change

WindowAction (Mouse x) Action
    causes the pager to execute Action when you click on a
    mini-window

> some situations. Would be nice to have.

What is the formula? I do not think that this is essential.

Olivier

---

From: Marcus Lundblad <[email-masked]>
Date: Sat, 4 Jan 2003 11:52:47 +0100 (CET)

> current plain rectangle taken from HilightColorset is really not enough.

What does this mean? 2 different colorsets used to draw the mini-windows,
will the title colorsets be used to draw just the title part of the
mini-window?

Just curious.
  
//Marcus

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 4 Jan 2003 12:51:26 +0000

On 04 Jan 2003 10:34:43 +0100, Olivier Chapuis wrote:
> I do not think this is difficult to implement.

I hope this refers to ActiveColorset.

> Only the fg colour

I don't think this will look correct/good.

You have a point that we need ActiveGreyedColorset too.
I didn't mean that only fg should be used in GreyedColorset, everything
including IconAlpha/IconTint/fgAlpha/Gradient/Transparent may be used.

I think I have a good solution for this that is also backward compatible.
We have one GreyedColorset that is a filter and forced to be Transparent.
It is applied to both MenuColorset and ActiveColorset (that itself may be
Transparent). I.e. the current

  MenuStyle * GreyedColorset 7
  Colorset 7 fg gray60

will work like it works now, but the following will work too:

  Colorset 7 fg parent, fgAlpha 50, IconAlpha 30

Image/Gradient/bg attributes may be ignored (because it is Transparent),
but Tint, if any, may be applied to normal or active menu items.

This (optionally) requires support for "fg parent", it may be useful
in other places too (FvwmButtons, FvwmIconMan).

> For me all these are post 2.6.

It would be more clean to implement this now. But it is OK to postpone it.

> the root window bg? We may add jpg (and svg) support in the future.

JPG is an issue because a lot of .jpg backgrounds that are compact (30Kb),
grow to 300Kb when converted to .png, regardless of a converter (xv, gimp,
convert). I am really puzzled by this fact. PNG has a good compressor.

But even if we leave the JPG issue, by default fvwm-root does not work
with RootTransparent and I think we will get a lot of user messages
wondering why transparent decorations or fast menus do not work. I think
it is reasonable to make -r default. Then a theme designer may always
suppose that RootTransparent is available. Or, like I suggested, he may
run fvwm-root with some parameters to ensure RootTransparent will be
available without forcing one specific backgound. I want to have a
solution to make RootTransparent work reliably.

>     causes the pager to execute Action when you click on a

I understand why two are needed, but I think that only first is useful,
the second would be somewhat confusing. A typical user may leave Mouse 1
for desk/page switching and only bind Mouse 2/3/4/5. So I suggest to have
only one WindowAction that is executed with a window context, so if a
user ever wants to emulate the second variant he may easily do it:

  *FvwmPager: WindowAction (Mouse 3) Menu WindowOps
  *FvwmPager: WindowAction (Mouse 2) GotoAndOnlyThenMenuWindowOps

  AddToFunc GotoAndOnlyThenMenuWindowOps
  + I GotoDeskAndPage
  + I Menu WindowOps

> What is the formula? I do not think that this is essential.

I don't know the formula yet. Do you always do tinting manually or use
XRender if available? Maybe XRender has something about HueRotation.

I may try to create the formula or find it on the web, but not now.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 4 Jan 2003 12:55:48 +0000

> will the title colorsets be used to draw just the title part of the

They would be used to draw the title of the pager desks, not mini-windows.
Run this command to see what this may mean:

  FvwmPager UnexistingConfig 0 3

Regards,
Mikhael.

---

From: Marcus Lundblad <[email-masked]>
Date: Sat, 4 Jan 2003 14:13:02 +0100 (CET)

>   FvwmPager UnexistingConfig 0 3

So it would be possible to use different colour for the desk labels than
the desk background (or use pixmaps as desk backgrounds and still have
coloured labels), that's pretty nice.

I was thinking about another feature for the pager. To allow to have an
extra border around the desks that could be given different colours for
active/not active desk.
This way it would be easier to know which is the active desk when not
using labels. It would also be possible to get a relief effect (so that
for example the desks looks like buttons where the active one is "pressed
in").

//Marcus

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 4 Jan 2003 14:03:55 +0000

> for example the desks looks like buttons where the active one is "pressed

Yes, the look of a pager could be improved, the only problem is that if it
is only one solid colored line border it will not look nice. I think it
is pretty difficult to design a nice look that is also configurable.

It is already possible to have raised in/out look if you use corresponding
images. Not exactly what you want, but I am pretty satisfied with:

  http://fvwm-themes.sourceforge.net/tmp/migo-FvwmPager.png

I don't know myself what I would prefer to see in place of "Work" title.
So even if this HilightTitleColorset is implemented it is still not
trivial to use it effectivelly. Of course, it would be better to have only
"Fun" titles and not to have to work, but this is not an option...

Regards,
Mikhael.

---

From: Marcus Lundblad <[email-masked]>
Date: Sat, 4 Jan 2003 20:07:49 +0100 (CET)

> is only one solid colored line border it will not look nice. 
I was thinking about using highlight and shadom from a colourset to draw
this border.
This way it would be possible to get both a flat and a beveled look.
Maybe the same thing could be done for the labels.
This way it would for example be possible to have the labels act like
buttons and have the active desktop surrounded by a distict coloured
frame.

> I think it
Yes, I agree.
For example, I like the look of "ov", the pager used by 4dwm in IRIX, but
something like this would be quite specific.

> images. Not exactly what you want, but I am pretty satisfied with:

Yes. But the problem is that the size can in some cases vary. For example
if you use DeskTopScale and use workstations with different resolutions
(or buy a bigger monitor :) )
 
> "Fun" titles and not to have to work, but this is not an option...

Yes, how about a new option:

fvwm --do-all-my-work now

^_^

//Marcus

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 4 Jan 2003 20:26:49 +0000

> buttons and have the active desktop surrounded by a distict coloured

Handling and drawing of such buttons does not seem an easy task to me.
Even without them, the pager has a bug now of not updating itself and its
resize hints correctly after DesktopSize command.

> something like this would be quite specific.

Actually, ov (Desks Overview) is a good example to see what and how.

  http://www.nekochan.net/albums/irix/IRIX2003.jpg

Probably my proposed [Hilight]TitleColorset may be [Hilight]FrameColorset
together with the option to configure desk view offset inside the frame,
so it would be possible to get the look of ov on this screenshot, but
without Menu/arrows/Global. Of course this means fixed-size images...
I would like to hear the Olivier opinion on [Hilight]FrameColorset.

Speaking about this screenshot, the framed icons are already possible.
Olivier, how about to rename IconBackgroundColorset to IconFrameColorset?

> (or buy a bigger monitor :) )

Not necessarily, there are high quality images that look good when resized
like on my screenshot. When I resize the pager two images are adjusted.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 4 Jan 2003 20:46:03 +0000

On 04 Jan 2003 20:26:49 +0000, Mikhael Goikhman wrote:
> > > Yes, the look of a pager could be improved, the only problem is that
> > > if it is only one solid colored line border it will not look nice.
> > 

After five more minutes of thinking. You can already get what you want
if you swallow several pagers (FvwmPager 2 2) in FvwmButtons. You may even
add a menu button and put this FvwmButtons into FvwmScroll to emulate ov.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 4 Jan 2003 21:29:43 +0000

On 03 Jan 2003 20:22:57 +0000, Mikhael Goikhman wrote:
> 
> 5) Colorset HueRotation (recoloring). Should be more useful than Tint in

This is really needed. Useful in alchemistry to convert water to gold.

According to this page, the formulas are pretty fast (no trigonometry
functions for rotation, quite a surprise), as fast as Tint:

  http://www.cs.rit.edu/~ncs/color/t_convert.html

So, the rotation formula for HueRotation(r, g, b, offset) is:

  (h, s, v) = RGBtoHSV(r, g, b);
  h = (h + offset) % 360;
  (new_r, new_b, new_g) = HSVtoRGB(h, s, v);

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 5 Jan 2003 07:27:51 +0100

> solution to make RootTransparent work reliably.

RootTransparent is a dangerous colorset option! The E method is a bad
hack: the E pixmap is an unprotected shared resource. This is very
bad, specially because the E pixmap may involve a lot of memory.

So, I think that -r must not be the default for fvwm-root.  User
should read the manual page. If a user discover the RootTransparent
colorset in the manual page, (s)he will be able to read under which
condition this colorset can work.

For fvwm-themes, you can always use the -r option if you want (but I
think that this is not the perfect solution). You may also create
fvwm-themes-setbg which may select the best set bg program and use the
appropriate option regarding the colors and colors-extra component.

Again, it is *not* possible (in general) to make a screenshot of
the root window bg.

Olivier

---

From: Marcus Lundblad <[email-masked]>
Date: Sun, 5 Jan 2003 12:38:39 +0100 (CET)

> Olivier, how about to rename IconBackgroundColorset to IconFrameColorset?

Actually, in 4dwm (and mwm,dtwm etc.), the decoration (frame) is the same
colour as the icon title (follows active/inactive state).
So maybe there could be IconFrameColorset/HilightIconFrameColorset that
defaults to IconTitleColorset/HilightIconTitleColorset.
And a style IconBorderWidth that sets the width of the border, would
default to 0, no border, the current behaviour.

//Marcus

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 5 Jan 2003 13:43:38 +0000

On 05 Jan 2003 12:38:39 +0100, Marcus Lundblad wrote:
> 
> > how about to rename IconBackgroundColorset to IconFrameColorset?
> 

I think the default should be like it is now - no icon frame colorset.
Even if IconTitleColorset is defined.

> default to 0, no border, the current behaviour.

Which one from the current IconTitleRelief, IconBackgroundRelief,
IconBackgroundPadding or IconSize do you mean?

Regards,
Mikhael.

---

From: Marcus Lundblad <[email-masked]>
Date: Sun, 5 Jan 2003 15:09:59 +0100 (CET)

> IconBackgroundPadding or IconSize do you mean?

I was thinking that the border comes outside of the icon background as it
is now. So there will be an inner rectangle corresponding to using:
Style * IconBackgroundColorset whatever
as it is now (including IconBackgroundRelief if not 0).

Then
Style * IconBorderWidth 5 (for example) will add a border outside the icon
background rectangle.

The question is if the the relief width of the border shall be the same as
the relief of the title. And what happens if a user sets the border width
smaller than the title relief.
Maybe when using icon borders, the relief shall be conbined with the title
relief. If you look carefully (xmag) on an MWM icon, you will see that the
border relief is 2 pixels wide but the relief lines immediatly above the
title (2 horizonal lines, one hilighted, one shadowed) is only 1 pixel
wide.
So the icon is drawed as one big rectangle with a 2 pixel relief.

I made a screenshot show this (icon.png)

I also made an image (icon2.png) show approximatly how a
Style * IconBorderWidth 2

would (possibly) look like with a relief of 2 pixels (inner relief of
border is 1 pixel), in combination with
Style * IconBackgroundRelief 1

I'm not sure what IconBorderWidth would do when not using
IconBackgroundColorset.
Should the interiour region still be transparent?

I see no problem in keeping the current behavoiur without IconSize,
though. Let the interiour region be as big as the picture (+ padding if
used) in this case.

//Marcus

---

From: Marcus Lundblad <[email-masked]>
Date: Mon, 6 Jan 2003 00:38:26 +0100 (CET)

> Even if IconTitleColorset is defined.

Actually I meant: IconBorderColorset/HilightIconBorderColorset
(I used the term border below). Or perhaps it should be called frame?
And IconFrameWidth.

But I think since we have "BorderWidth/HandleWidth" for windows, it's more
logical to use the term border also for icons.

//Marcus