Subject: CVS olicha: * MultiPixmap can use Colorset ans Solid color

From: FVWM CVS <[email-masked]>
Date: Mon, 16 Dec 2002 09:24:14 -0600

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	olicha	02/12/16 09:24:14

Modified files:
	.              : ChangeLog configure.in 
	fvwm           : borders.c builtins.c fvwm.c screen.h 
	libs           : Graphics.c PictureGraphics.c PictureGraphics.h 
	                 defaults.h 

Log message:
* MultiPixmap can use Colorset ans Solid color
* "Merge" the MultiPixmap code with the regular drawing code and remove
the FANCY_TITLEBAR ifdef
* The syntax is:
MultiPixmap Main {Colorset,Solid,TiledPixmap,StretchedPixmap} {cs,color,file}...
the old syntax is supported.
* Various improvement in MultiPixmap:
- You can really add to title style
- UseTitleStyle use a grouped logic (e.g., LeftButtons Colorset cs applies
the colorset cs to the left buttons rectangle and not to each left buttons)
- {Left,Right}OfText and {Left,Right}End can be StretchedPixmap: there are
"YStretched"
- Sticky lines placement
* New {Title,Button}Style style StretchedPixmap
* New libs interface function: PGraphicsCreateTiledPicture
* Added a global (Scr) alpha GC

--
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: Mon, 16 Dec 2002 17:32:26 +0100

> - {Left,Right}OfText and {Left,Right}End can be StretchedPixmap: there are

Suzanne can you try your various themes and report any pbs?

I saw some pbs with multi part priorities.
The logic is as follows (I tried to do not modify it at any essential
point but maybe I miss something):
 - If we have the space to draw the full text draw it
 - Then, If we have the space for the LeftOfText image draw it
 - Then, If we have the space for the RightOfText image draw it
 - Then, If we have the space for the LeftEnd image draw it
 - Then, If we have the space for the RightEnd image draw it
So the priorities are:
  UnderText, LeftOfText, RightOfText, LeftEnd, RightEnd

Maybe it will be better to make some grouping. Always draw or
do not draw both LeftOfText and RightOfText.  Always draw or
do not draw both LeftEnd and RightEnd. That is using the following
priorities:
 UnderText, (LeftOfText/RightOfText), (LeftEnd/RightEnd)

Also, Maybe it will be better to use the following priorities:
  (LeftOfText/RightOfText), (LeftEnd/RightEnd), UnderText
at least for long title?

Suzzanne, Mikhael?

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 16 Dec 2002 18:26:26 +0100

> * New {Title,Button}Style style StretchedPixmap

I've added this because I think this useful and because it was a one
line patch after the MultiPixmap merge. But in fact I think that
something like "FitStretchedPixmap" is more useful (an other "one
line patch"): stretch the pixmap only if it is to big for the
destination.  Does someone has a better name than "FitStretchedPixmap"?

About names. I think that we should have a new Style which rotates
(always CW) the TitleStyle decorations. What about

  RotateVerticalTitleDecor / !RotateVerticalTitleDecor

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 17 Dec 2002 02:22:22 +0000

> destination.  Does someone has a better name than "FitStretchedPixmap"?

I hope I understand this correctly. I am sure there is a term in the
image processing field for this. If not, maybe:

  SprainedImage

Yes, I want to start to refer to XBM/XPM/PNG files as "Image" in user
configs as more intuitive. If you want I may rename all new names.

Actually I think that the current TitleStyle Pixmap should behave this
way, so no new option is needed. It seems pretty useless currently and
we may just change it to be more useful when sprained.

If you are at it, can you please fix the problem with Pixmap/TiledPixmap
in 2.5.x. An image is drawn at +2+2 if title is raised/sunken. I think
that the correct way is to handle it as in 2.4.x. I.e. it should always
start at +0+0 and the following commands should only add/remove relief
over the static image rather than shifting it.

  TitleStyle Active -- raised
  TitleStyle Active -- flat

>   RotateVerticalTitleDecor / !RotateVerticalTitleDecor

I would like if it is _always_ rotated by -90/+90/+180 depending on the
rotation of the title text. So this +90/0 flag would be redundant for me.
I am pretty convinced we don't need unrotated vertical title decorations.

  LeftTitleRotatedCW   - rotate both text and decorations by +90
  !LeftTitleRotatedCW  - rotate both text and decorations by -90

The button order is not affected by this, only text/image rotation.
We should remove LeftTitleRotatedCCW, since we have !LeftTitleRotatedCW.

More comments later after I actually try the new functionality.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 16 Dec 2002 21:39:02 -0500

> image processing field for this. If not, maybe:

I don't think sprain is the right word.

Sprain:
       1.
       (tr.) to injure (a joint) by a sudden twisting or wrenching of its
       ligaments.
       2.
       the resulting injury to such a joint, characterized by swelling
       and temporary disability.

Is the image streched or shrunk?  It sounds like its shrunk,
never streched.

I think the options are:

shrunk (made smaller)
streched (made bigger)
fit (streched or shrunk)

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 17 Dec 2002 03:24:05 +0000

>        and temporary disability.

My one word to one word local translator translates it to the synonym of
"streched". Poor bad dictionary, sorry.

> Is the image streched or shrunk?  It sounds like its shrunk,

Actually there are more options. :)

For example, try the current:

  TitleStyle Active Pixmap /any/image.png

If title width is small, only the left part of image.png is shown.
If title width is big, image.png is centered. Kind of FixedImage.

For me this is useless. What I and hopefully Olivier mean is this:
If title width is small, only the left part of image.png is shown.
If title width is big, image.png is streched.

This time my both dictionaries agree on the word tensile. TensileImage.
Or just Image (alias of Pixmap) if we change the behaviour.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 16 Dec 2002 22:41:13 -0500

Mikhael Goikhman <[email-masked]> writes:
> "stretched". Poor bad dictionary, sorry.
> 
> > Is the image stretched or shrunk?  It sounds like its shrunk,
> > never stretched.
> > 
> > I think the options are:
> > 
> > shrunk (made smaller)
> > stretched (made bigger)
> > fit (stretched or shrunk)
> 

Well, I was afraid of that...

> If title width is big, image.png is stretched.

I think it makes sense to attack this from the point of view of the
image, not the container.  Ie.

If the image is larger, its truncated.
If the image is smaller, its stretched.

Truncation is a little bit like the null case, Ie. nothing is
done to the image.  So I think I'd still go with stretched.

> Or just Image (alias of Pixmap) if we change the behaviour.

I have access to a bunch of online dictionaries but they are behind
the Telcordia firewall:

[OALDCE]

      tensile /'tensaIl US: 'tensl/ adj

      1. of tension: measure the tensile strength of wire, eg to find the load it will support without breaking.

      2. capable of being stretched.< 

[W7]

      tensile 3 aj
      'ten(t)-s*l, 'ten-.s{i-}l
      1 aj capable of tension : [mini DUCTILE]
      2 aj of or relating to tension
      tensility 331 n
      ten-'sil-*t-{e-} 

[LDOCE]

      ((tensile)
            (1 T0047200 %< ten *80 sile)
            (3 %"tensaIl = %"tensFl)
            (5 adj %<)
            (6 %< tech)
            (7 100 %< Wa5 %; A %< ---- %< --K-T---Y)
            (8 of or related to *CA TENSION *CB (1 %, 2) : *46 The
                  tensile strength of a rope tells you how much
                  weight it can hold without breaking)
            (7 200 %< B %< ---- %< --K-J)
            (8 that can be stretched : *46 tensile rubber)) 

[RHD]

      (tensl, -sil or, esp. Brit., -sl), adj.

      [1] of or pertaining to tension: tensile strain.

      [2] capable of being stretched or drawn out; ductile.[1620-30; NL tensilis. See Ã.¥Â.?, -^(TM)£.]tensility (tensilite), tensileness, n.tensilely, adv. 

[CED]

      ten+sile (#!t$ensa$Il) adj.

      1. of or relating to tension.

      2. sufficiently ductile to be stretched or drawn out.

      3. Rare. (of musical instruments) producing sounds through the vibration of stretched strings. [C17: from New Latin tensilis, from Latin tendere to stretch]

      ?-#!ten+sile+ly adv.

      ?-ten+sil+i.ty (t$en#!s$Il?!$It$I) or #!ten+sile+ness@fn. 

[Macquarie]

      Word:  tensile

      Pron:  ['t8nsa1l]

      1 adj. - of or pertaining to tension: tensile stress.

      2 - capable of being stretched or drawn out; ductile.

      Etym:  [NL tensilis, from L tendere stretch]

      Related:   tensility [t8n's1l7ti], n. 

(The things in brackets [] are the dictionary names.)

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 17 Dec 2002 06:05:42 +0100

> configs as more intuitive. If you want I may rename all new names.

I've no real opinion but no objection. But the "Pixmap" syntax should be
supported.

> we may just change it to be more useful when sprained.

I am agree. Any objection? There are 2 pbs: (i) backwarde compatibility
and (ii) ressource usage (e.g., when you resize a window at small size
each buttons will be resized).

>   TitleStyle Active -- flat

One can see this as a new functionality: it is useless to draw the
pixmap under the relief. Say you have a 22x22 image button set with
Pixmap on a 22x22 raised title bar button, then it seems clear to me
that we should resize the image button to 18x18 and apply it at +2+2.
Maybe for TiledPixmap we should always start at +0+0, I do not
know. But I do not see pbs for Pixmap.
 
> We should remove LeftTitleRotatedCCW, since we have !LeftTitleRotatedCW.

Yes, but some decoration is symetric (a solid color, a centered gradient,
some TiledPixmap decoration, RootTransparent) and the rotation of the
decoration will use some resource. I see  RotateVerticalTitleDecor as
an attribute of the decoration. Yes, the rotation should follow the
text rotation (but the individual buttons should not be rotated and
the buttons set should be rotated CW).

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 17 Dec 2002 06:43:05 +0100

> > If title width is big, image.png is stretched.

I am not sure to understand.
 
> If the image is larger, its truncated.

This is the current Pixmap behavior

> If the image is smaller, its stretched.

The new StretchedPixmap do this, but also if the image is larger it's
resized to fit into the destination. Is "FitPixmap" ok for this?

We may add this behavior (If the image is smaller, its stretched, if
not do nothing) and name it StretchedPixmap (it is easy).

I do not want to add one tone of new Pixmap style type now (related to
tile and x/y directions). I see one style type which is useful *and*
easy to implement (I do not want to spent 2 hours or more to debug 10
new complicate style type): If the image is smaller do nothing (as
Pixmap), if the image is larger resize it to fit into the
destination. Is "ShrunkPixmap" ok?
--
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: Tue, 17 Dec 2002 18:43:12 +0000

> each buttons will be resized).

I would not consider (i) as a problem, it was never documented that the
image is centered when smaller than title, so a user can't rely on this.
But I am not sure what is (ii). I thought that when the image is larger it
should not be shrunk, only truncated, so please explain (ii) again.

> that we should resize the image button to 18x18 and apply it at +2+2.

If you can shrink the 22x22 icon to 18x18, it is ok (but is it nice?).
It is also fine with me to truncate this icon to the central 18x18 region.
What is not fine with me is to trancate it to the left-top 18x18 region
throwing away 4 right and 4 bottom pixels complitelly.

> know. But I do not see pbs for Pixmap.

The problem is that the title width is fixed and it does not take into an
account relief at all, so image should not take relief into account too.
For me, if title height is not changed when you execute 2 commands above,
i.e. when relief is added or removed, the image should not be shifted.
Taking a central part and applying it to +2+2 would be the same.

> the buttons set should be rotated CW).

For me, tiled images and even mini icons should always be rotated too! :)
A centered gradient in titles is rare, so rotating it is not a problem.
Of course for transparent parts rotation is void.

I can't imagine a titlebar design where this boolean flag would be useful.
But if you want to have it as boolean, I have no problem. I just think
that "Vertical" name would not be exact. Maybe [!]UseTitleDecorRotation,
(defaulting to 1) since we may have +180 rotation too.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 17 Dec 2002 21:58:23 +0000

> I am not sure to understand.

The first if-else refers to the current Pixmap that we want to replace.
The second if-else refers to how I understand your original suggestion.

> resized to fit into the destination. Is "FitPixmap" ok for this?

FitPixmap is ok, but sounds unnatural to me. Looking at the dictionary...
AdjustedPixmap or Pixmap (this behaviour is good to be a default).

> not do nothing) and name it StretchedPixmap (it is easy).

StretchedPixmap or Pixmap (this is good to be a default too).

> destination. Is "ShrunkPixmap" ok?

The name is ok, but I don't think it is very useful (centered image).
I listed the only useful cases for me in another thread: fit/tile/stretch.

I would only support these image convertion options in Colorset.
All *Pixmap that are not colorset options may be supported, but obsolete.
For me the only good syntax, open for extensions, is:

  Colorset n Image|SecondImage|Shape [Tiled|Stretched|Adjusted] image.xpm

The default is either Stretched or Adjusted, I don't care.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 18 Dec 2002 22:33:02 +0100

> If you can shrink the 22x22 icon to 18x18, it is ok (but is it nice?).

Not always nice it depends. Our resizing algo a really weak but I
do not think that we have the time to implement elaborated resizing
algo.

> > know. But I do not see pbs for Pixmap.

I do not know. Any way you will not have this problem with MiltiPixmap
and Colorset.

Dominik, I think it is you whose adds this +2+2 offset so maybe you
can comment on this?

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 18 Dec 2002 22:19:19 +0100

> The name is ok, but I don't think it is very useful (centered image).

I think it is. All this is essentially for buttons. I will add
StretchedPixmap, AdjustedPixmap, ShrunkPixmap and left Pixmap
as it is now. So everybody will be happy.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 22 Dec 2002 08:13:59 +0100

> > > We should remove LeftTitleRotatedCCW, since we have !LeftTitleRotatedCW.

At present time I think that either:

1 - Title Decoration is always rotated CW (as the buttons order)

Or

2 - title text, title Decor _and_ buttons order should follow
*TitleRotatedC{C}W.

1 is probably more simple and maybe 2 can leads to some unexpected
difficulty. Is 1 unacceptable?

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 22 Dec 2002 11:51:47 +0000

On 22 Dec 2002 08:13:59 +0100, Olivier Chapuis wrote:
> > > > I would like if it is _always_ rotated by -90/+90/+180 depending
> > > > on the rotation of the title text. So this +90/0 flag would be
> > > > redundant for me. I am pretty convinced we don't need unrotated
> > > > vertical title decorations.
> > > > 

For me, (1) is not very meaningful. Why to enable to rotate decorations
only by 0 or +90, what about -90 and 180? Some texts with shadows may only
look as intended in the same polarity with decorations, so for me it has
no much sence to be able to rotate text by -90 and not the decorations.

I would really prefer (2), this will simplify everything. Dominik
originally implemented such strange button rotation (either 0 or +90) just
so there is the same button order for TitleAtTop and TitleAtBottom. But
now we have a more configurable setup where _each_ title direction may be
separately configured to be rotated in one or another way, so there is no
any reason not to rotate buttons together with the rest of the title -
text and decorations. I am strongly for (2), this way we don't need any
additional option and everything is still fully compatible with 2.4.
Only the button rotation in the TitleAtLeft is changed from +90 to -90 by
default, for me it is a consistent change.

  (1) - complicated to understand together with *TitleRotatedCW, provides
  unneeded functionality, does not fully provide needed functionality
  (2) - intuitive and fully provides needed functionality

Regards,
Mikhael.