Subject: CVS olicha: * Completed UseTitleDecorRotation new Style

From: FVWM CVS <[email-masked]>
Date: Fri, 27 Dec 2002 18:00:20 -0600

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	olicha	02/12/27 18:00:20

Modified files:
	.              : ChangeLog 
	fvwm           : ConfigFvwmDefaults borders.c 
	libs           : Graphics.c fvwmlib.h 

Log message:
* Completed UseTitleDecorRotation new Style
* UseTitleDecorRotation is a default do not know if this is a good idea

--
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, 28 Dec 2002 02:25:07 +0000

> * UseTitleDecorRotation is a default do not know if this is a good idea

I like the result!
Should buttons (the content) be rotated too in the long run?

I am a bit biased against !UseTitleDecorRotation, since I can't think
about its usage, but if this is not a default it is ok with me.

Nice that you continue to support a 180 rotation.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Fri, 27 Dec 2002 21:28:46 -0500

> > * UseTitleDecorRotation is a default do not know if this is a good idea

I'm not tracking all this fancy stuff but I'm wondering why there
are no man page updates?

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

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 28 Dec 2002 07:38:26 +0100

> I'm not tracking all this fancy stuff but I'm wondering why there

Yes, I've some delay with the man page. I need to document LocalePath,
Colorset in decor style and UseTitleDecorRotation and maybe more
soon. I will document all these before 2003-01-07. Sorry.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 28 Dec 2002 07:28:23 +0100

> Should buttons (the content) be rotated too in the long run?

No I think that buttons must not be rotated. But note that the
UseTitleStyle part of the Buttons decor is rotated.  A ButtonStyle
Pixmap is a brain "mark" image, if you rotate it you will trouble users
(what can even happen, if you rotate buttons, is that a given button x
in a rotated title can look as button y in a non rotated title, with x
!= y).  Ok, some fvwm-themes themes will look better if we rotate
buttons, but it is fvwm-themes which should be fixed not fvwm:
blackbox, mech, metal (maybe), nanoGUI should be converted to
MultiPixmap.  MultiPixmap themes should be fixed by decomposing the
background of the buttons and the real buttons. The bg of the buttons
should be set via UseTitleStyle with the {Left,Right,}Buttons options.
   
> about its usage, but if this is not a default it is ok with me.

With UseTitleDecorRotation drawing a title window use more X resource
as some Pixmaps should be rotated (FGetImage, rotate an XImage,
FPutImage).  For some decorations it is not useful at all to rotate
the title decorations. !UseTitleDecorRotation allows to really save
resource.

> Nice that you continue to support a 180 rotation.

Can you recall my why this is useful ? :o)

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 28 Dec 2002 08:03:49 +0000

> should be set via UseTitleStyle with the {Left,Right,}Buttons options.

My brain says that if everything is rotated, button foreground should be
rotated too. I can see your points if a brain of anyone suggests that
button images should be fixed forever. I don't have a strong opinion here.

One reason for button rotation is this, we may fix fvwm-themes, but not
everyone knows how or wants to do it, or has transparent images.
For example, most of buttons on the Suzanne's page use non-transparent
images, so they look incorrectly for side titles without rotation.

> Can you recall my why this is useful ? :o)

1) For symmetry and consistency with vertical sides.
2) For correctness of some highly assimetrical titlebars that require that
   title is always directed to the center, i.e. rotated around the center.
   Think about a future !TitleBorder - one of 4 window borders is disabled
3) For fun. Are other WMs have this?
4) You never know when the skills to read a 180 rotated text will be
   useful. Think, either your keyboard or display or you is rotated. :)
   Clowns and cosmonauts may appreciate this. :)

Regards,
Mikhael.

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Sat, 28 Dec 2002 12:52:06 +0100

> Pixmap is a brain "mark" image, if you rotate it you will trouble

Well, I may be a weirdo, but I personally am troubled more by the
not-rotated buttons. I would say that it requires more "brain work" to
assemble the rotated title bar into something familiar if the buttons
are not rotated (because the brain already rotates the whole image (the
text IS rotated) as to "understand" it, and then it has to rotate the
buttons again (because they don't play along with the, already rotated,
text). So it's twice the work for the brain - If you happen to "see" the
titlebar as a whole, and not as "rotated text"+"not rotated buttons".

So I would be for the rotation of the button pixmaps. Pretty please :)
(Of course as an toggle-option)

Furthermore, it's just that there are themes that simply require the
rotation of buttons. The current rotation feature is great, but if
a theme uses not-so-symmetrical buttons you will never *want* to rotate
the titlebar - because the theme will start to look ugly, or it will
simply lose it's "magic". Unless the buttons get rotated together with
the text/background pixmaps.

-- 
\hoppke
(Grzegorz Nieweglowski)

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 28 Dec 2002 22:56:00 +0100

On Sat, Dec 28, 2002 at 12:52:06PM +0100, Grzegorz Nieweglowski wrote:
> Olivier Chapuis nawypisowywa³(a):
> >> I like the result!

About text rotation and the brain: say that you have a window with
name "rxvt". When you read the window title you do not read the "r",
then the "x" ... and finally the the "t". Your brain directly recognize
the full word "rxvt". So text rotation is good because you have
the word "rxvt" horizontally written is your brain (as a motif) but not:
   
    r
    x
    v
    t

in any given direction. There is an interesting discussion on which
rotation (cw or ccw) is the best one somewhere in the fvwm-workers
archive.

Let's come back to our ship: buttons. We should recognize the good
button as fast as possible: if I want to maximize a window I want
to find my maximize button. It is clear that if the maximize button
is not rotated you will find it more easily. That's all.
Some examples:

Menu button:  |\   Iconify button:   --   Maximize Button: /\
              |/                     \/                    --

If you rotate cw the buttons, then menu button looks like the
iconify button. If you rotate buttons, which buttons is the
maximize button, which one is the iconify button?

> rotation of buttons.

Which themes? themes from fvwm-themes? themes from Suzanne?  All these
themes have been designed before vertical titles.  IMHO, they should
be redesigned (and MultiPixmap may help a lot).  Often a button has
two parts a background (e.g., a grey gradient, often this bg is
"common" to all the buttons) and a "foreground" (the real button:
"maximize", "menu", "iconify", ...etc.). The solution is to use
"UseTitleStyle" in ButtonStyle for defining the background (this
is rotated) and to AddButtonStyle the various foreground buttons.
Note that with a Colorset or a MultiPixmap TitleStyle, "UseTitleStyle"
is powerful as the set of buttons is incorporated in the TitleStyle
decor (for example with a Colorset HGradient the gradient is drawn
on the full bar (title+buttons) and not repeated on each buttons).

Of course, one can implement something like

   {Stretch,Shrunk,Tiled,Adjusted,}Pixmap (AllowsRotation) file

in ButtonStyle. But I am not sure this is a good idea. This may
leads to some terrible fvwm config decoration hack (as the current
nanoGUI fvwm-themes theme). 

> The current rotation feature is great, but if

Do you have an example that cannot be fixed by a clever config?

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 28 Dec 2002 23:16:20 +0000

> maximize button, which one is the iconify button?

Actually, even in your example, such buttons usually have a light source,
so they are not fully symmetrical and probably not easily confusable.
But maybe just to have a button rotation flag as a property of buttons?

> nanoGUI fvwm-themes theme). 

I would not do this too, a better way is to have one flag for all buttons:

  Style * UseButtonImageRotation  # UseButtonForeRotation?

similar to UseTitleDecorRotation and activated only when the last is set.
Of course, almost noone else can easily implement it and you are pretty
overloaded with all the wonderful recent work, so it is your decision.

> Do you have an example that cannot be fixed by a clever config?

I think Grzegorz says that the brain does more work with title rotation
and no button rotation, so any config would be an example here.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 29 Dec 2002 14:28:03 +0100

> so they are not fully symmetrical and probably not easily confusable.

I will say that light source rotation will add to the confusion.  The
light source come from the top left of the screen (and the brain know
that!). I do not think that the light source should be rotated it is a
property of the all screen (example: with a 180 rotation raised will
become sunk!! with a 90 rotation you have a raised-sunk relief). Note
that for title the relief is not rotated (if you rotate you get
various catastrophic result).

> and no button rotation, so any config would be an example here.

Really I do not understand. How it is possible to say that a rotated
real button (a fg button) will be easily recognized than its normal
version. What I can understand is that some current config will
_globally_ look better with buttons rotation. If we add a new style
for that what will happen is that some config will not be fixed.
Then, as I think that buttons rotation is erroneous from the usability
point of view I do not think that I will have the time to implement
any buttons rotation.
 
Olivier

---

From: Grzegorz Niewęgłowski <[email-masked]>
Date: Sun, 29 Dec 2002 12:55:17 +0100

> is not rotated you will find it more easily. That's all.

Only if you are lucky (or skilled) enough to be able to actually force
your brain into distinguishing between "title text" and "title buttons".
I can't do this, for me it doesn't matter "text or image". Reading
rotated text and not-rotated buttons is like reading a text in which one
word has it's letters rotated by 90°, and the next word is "normal".

But that could very well be only my problem.

> maximize button, which one is the iconify button?

The one that points to the "down" side of the title text. That's the way
I figure it out.

It's the same as with text - you don't read it one character at a time,
you see the text as a whole, and the brain rotates it. But my brain does
this not only for the text, but for the whole titlebar at once. The text
is just a "marker" for the brain that allows it to quickly recognize how
the titlebar has been rotated. Rotated buttons are as easy to "read" as
rotated text.

> Which themes? themes from fvwm-themes? themes from Suzanne?

No, my themes. I'm coming from Sawfish, and, well, nobody ports the
themes I'm used to:
http://www.sniper.kolmio.pl/public/hoppke/elberg.jpg
(Here the buttons are asymmetrical enough not to cause trouble in
"understanding" their meaning, but exactly this causes new troubles
- it's very easy to see the titlebar as "one", and not as a composition
of text and various buttons. Because there's so little symmetry, the
brain doesn't pick up enough "patterns" to divide the image into
functional blocks. And it learns to expect the buttons and text in this,
and only this one and special relation.

> The solution is to use "UseTitleStyle" in ButtonStyle for defining the
> background (this is rotated) and to AddButtonStyle the various
> foreground buttons.

That's the way I do my decors, but still - it isn't actually the
button background - it's the foreground pattern that counts.

> nanoGUI fvwm-themes theme). 

Well, that would be powerfull, as you could choose to rotate button1,
and leave others intact. But I guess that a Style option
"AllowButtonRotation" or something like that would do the trick as well,
and would fit just fine.

>> The current rotation feature is great, but if a theme uses
>> not-so-symmetrical buttons you will never *want* to rotate the
>> titlebar - because the theme will start to look ugly, or it will
>> simply lose it's "magic". Unless the buttons get rotated together
>> with the text/background pixmaps.
> 

Say... Kliin. An IceWM theme, trivial to port. The "magic" concerns the
leftmost and rightmost buttons. A (very bad quality) screenshot is
available on freshmeat, http://images.freshmeat.net/screenshots/30637.png
(I could post a tarball with the decor+sample config after porting to
fvwm, less than 3KB, if the screenshot should really be that unreadable)

The "catches" are the horizontal lines that "sprout" from the sidemost
buttons. If these lines don't get rotated, Kliin just isn't what it used
to be.

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Sun, 29 Dec 2002 19:16:29 +0100

Olivier Chapuis wrote:

>> I think Grzegorz says that the brain does more work with title
>> rotation and no button rotation, so any config would be an example
>> here.
> 
> version.

It's context-related. When you start to "see" things rotated, it makes
no trouble to "read" a rotated button. You already have "switched" from
"normal view" to "rotated view" when trying to read the title text. So
you just stay in that mode and read the buttons. If the buttons aren't
rotated, the brain has to "switch" more times - "rotated view" to read
the text, then again "normal view" when looking at the buttons. It can
cause confusion, especially if you add a rotated background pixmap,
with rotated shading (light source/background pattern). The trick is
- not everyone distinguishes text/button image. For me, it's just
"titlebar" If it's spotted as rotated, it makes no difference if the
rotated "thingie" is a letter, or a button. The brain "unrotates" it for
me automagically. Yeah, I guess that's the key - do not treat the title
as something special - the title is just a pattern on the titlebar. Just
like every other pixel group.

> What I can understand is that some current config will _globally_ look
> better with buttons rotation. If we add a new style for that what will
> happen is that some config will not be fixed.  Then, as I think that
> buttons rotation is erroneous from the usability point of view I do
> not think that I will have the time to implement any buttons rotation.

This will, however, make the whole "rotation" feature quite unusable in
many situations. It will be good only with simple themes, others will
get mutilated. I really appreciate the work you're doing, it's great,
it's just that without rotating buttons it will stop half way up the
hill. Already it is possible to rotate the title-background pixmap. It
can contain more than just a Solid color, it can be a shaded pixmap
that, when rotated, changes it's lightsource relation (I have a theme
shaped after mozilla-modern-2, exactly this case - a pixmap of light
blueish fading into a darker shade of blue - when rotated, the buttons
get a completely new relation to the lightsource (the background
gradient)

So there already exists the possibility to make things look weird and
inconsistant. If the button pixmap isn't a square, circle or something
of equal symmetry, then you really notice really fast that it just
doesn't look right. I don't know how this concernes fvwm-themes or other
equally popular decorations, as I don't use them (too complex and
complicated IMO), but I believe that there are many fvwm-users out there
who invent their own themes. And just looking at fvwm-themes and saying
"It will look good when MultiPixmaped" may not be true for many users.
I just try to point out that there is no danger in implementing a Style
sister-option to UseTitleDecorRotation, and it will most propably make
it way, way more usefull for some themes and people with eyes that
strangely have problems with reading mixtures of rotated/unrotated
patterns. I don't know how much additional work this would cost you, I'm
no coder, but you certainly are the person that could do it best - you
already know the code and know how to do it. I'm not pushing "do it
quickly", I just wouldn't like you abandoning the idea of doing it at
all. Because the title rotation could be a real beauty. If it could
rotate the whole titlebar.

And the rotation thing should not be seen as a way to force people into
transition to MultiPixmap :) It would be enough (and simpler) to put
some bugs into everything different from MultiPixmap ;)

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 30 Dec 2002 03:02:20 +0000

I know why Grzegorz is so ardent about button rotation. :-)
He does not like how his buttons are not rotated here:

  http://www.sniper.kolmio.pl/public/hoppke/screen2.png
  
I thought to send this as a joke, since it is obvious that the buttons
are fully symmetrical, so they don't need any rotation.

But after finding the config, it is unfortunately not a joke. Buttons
include the (non symetrical) background including the hardly noticeable
one pixel line at the bottom. So they look incorrect without rotation.

Here I fully agree with Olivier. Please for the everyone's sake use
transparent images for buttons and UseTitleStyle, this way the buttons are
fully reusable with other titlebar backgrounds too.

For me, button rotation is not the most urgent thing and not even needed
for 2.6.0, but Olivier decides here. Correct configurations should look
acceptably well without it. Of course there are very rare titlebar designs
where it is hard to separate button foreground from button background. But
for me having correct configurations for most of titlebars (like the one
on the screenshot) is more important than supporting a correct rotation of
rare titlebars.

Regards,
Mikhael.

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Mon, 30 Dec 2002 14:08:47 +0100

>   http://www.sniper.kolmio.pl/public/hoppke/screen2.png

:) Oh. Nah, that's an old config. Guess I should update (delete) it...
(Damn, you've found it ;)

This was the first theme I made for myself. Couple of days after
I started using fvwm. Yes, this theme would do nicely even without
rotation. The buttons are quite easily made transparent, but I never got
to it.

I hope I don't get too many flames for sending a small sample - Kliin
decor. It's a small sample, just unpack it somewhere and "Read" the
"kliin/theme" file in a running fvwm. Should setup itself correctly in
most environments. Mouse bindings are simple, it's just an example, not
meant for real use.

Transparent, multipixmaped, all that stuff. And a little bug after
rotation, the small lines on buttons 1 and 2 look, well, ah, see it for
yourself. But let's leave the boring rotation-thingie behind:

More importantly, it can show a cvs-fvwm bug. The maximize button uses
the MwmDecorMax hint. Somehow buttons with MwmDecor (those of the
"Toggled" art, like ToggledActiveUp etc.) don't get the right background
with UseTitleStyle. Instead the "toggled" buttons seem to use the
HilightBack/BackColor settings (although these should get "overruled" by
UseTitleStyle, at least that's the case with "normal" buttons)

Try removing/changing the HilightBack/BackColor lines from the theme,
and then maximising a window. The MwmDecorMax button will get the
'default color' background, it just doesn't respect UseTitleStyle. This
isn't too much of a problem in simple themes (like Kliin), but any
titlebar background different from a Solid color makes using MwmDecor*
buttons difficult. Or am I doing something terribly wrong? I mean, a
"ButtonStyle All -- flat usetitlestyle" should do the trick, but it
does not.

-- 
\hoppke
(Grzegorz Nieweglowski)

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 30 Dec 2002 16:22:16 +0000

On 30 Dec 2002 14:08:47 +0100, Grzegorz Nieweglowski wrote:
> 
> Transparent, multipixmaped, all that stuff.

Just a note. Olivier didn't mean you should always use MultiPixmap.
Only to avoid such hacks as in nanoGUI theme. In your configs (both on
the screenshot and attached) MultiPixmap is not really needed, a mere
Solid or TiledPixmap is enough.

> And a little bug after rotation, the small lines on buttons 1 and 2
> look, well, ah, see it for yourself. But let's leave the boring
> rotation-thingie behind:
> 

These are actually "overruled" for all states you specified in TitleStyle.
You didn't specify Toggled states, so it uses HilightBack/BackColor as
expected. As a side note, I would suggest to use colorsets for everything
instead.

> "ButtonStyle All -- flat usetitlestyle" should do the trick, but it

To fix this, you may specify AllInactive and AllActive in TitleStyle
instead of Inactive/Active. Or specify ToggledInactive/ToggledActive.
Yes, even though TitleStyle itself does not use Toggled states (as well
as some MultiPixmap images too), they are used in UseTitleStyle buttons.

Regards,
Mikhael.

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Mon, 30 Dec 2002 19:06:48 +0100

> Solid or TiledPixmap is enough.

Aaa... nope. I _had_ to use MultiPixmap, cause the Solid title style
thingy was acting strangely in my CVS snapshot (at the time of writing
kliin). The color "bar" was shifted about 4 pixels from the top and left
side (the titlebar had wide "stripes" of uncolored space at the top and
left. Yes, it was "flattened"). Maybe I just snatched a snapshot in a
wrong moment. Now I'm using fvwm-2002-12-28 and

TitleStyle Height 16 Active (Solid #ccccee) \
Inactive (Solid #dddddd) -- flat

works as expected. But it didn't the last time I tried it, honest.

> Yes, even though TitleStyle itself does not use Toggled states (as
> well as some MultiPixmap images too), they are used in UseTitleStyle
> buttons.

And it's all in the man page. I must have gone blind and didn't even noticed.
I feel so silly. Sorry everyone :)

Thanks for correcting me :) I simply wouldn't have expected that Toggled
buttons have the ability to get a separately defined background. But,
this is fvwm. The land of pathological configurability ;)

PS. I tried to reply to your mail, but your email provider rejects
connections from my machine, guess it's because I don't have a static
IP. The fvwm-* lists have similar safety mechanisms, but I managed to
fool them. homemail.com however isn't that easy to trick. Perhaps you
have an account by some other provider?

But my answer would be "Yes, I guess I could do it. I haven't seen any
transparent pixmaps, but I've just tried adding the transparency myself
and it should look good. However, I'm not really having enough time
right now. Studying and all... I'll be preoccupied 'till February, at
least.  But if that delay would be acceptable, then it's OK."