Subject: Re: Rotated Font

From: Olivier Chapuis <[email-masked]>
Date: Thu, 09 Dec 1999 23:45:40 +0100

Olivier Chapuis wrote:
> 
> Hello Dominik,
> If you decide to add the Style TitleOnTheLeft, I am ready to add to
> the library the rotated X font utility of Alan Richardson (under GPL,
> it is used in wmx and wm2). I study a little bit this "library" and look
> at the fvwm border code and perhaps this will simplify the implementation
> of TitleOnTheLeft and will give a better look than a title of the form
> 
>   x
>   t
>   e
>   r
>   m
> 
> There is only a little work to do on this utility to put it in libs/
> (in particular add some internal doc).
> Olivier

Hello,
So, I put the rotated library in my archive for the 2.5.x series ?
Or maybe I have two (maybe I need 4) months to implement title on 
the left/right ?
Sorry to bother every body with this but I think that this is the only
important thing (with a GUI config module with "theme" support) that fvwm 
do not have. Of course this is subjective ... 
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: Dan Espen <[email-masked]>
Date: Thu, 09 Dec 1999 18:36:08 -0500

> do not have. Of course this is subjective ... 

You got no response at all the last time you brought this up.
Whether its a good idea or not, that must be frustrating.
Lets see if I don't stir this up a bit...

I felt titlebars on the bottom went too far.
In the past when we discussed frame decoration going completely crazy,
it was always on the condition that it would move into a module.

On the other hand, I no longer have access to a slow machine and I only
have 3 or 4 users at work using fvwm on slow machines.

Given the shape of most monitors, aren't titlebars on the window sides
a feature that will never get used?

If you  rotate the font, its  still not going  to  be readable without
turning the monitor on its side.

OK workers, if you want titlebars on the sides of windows with rotated
fonts, say so...

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Fri, 10 Dec 1999 13:11:32 +0100

> > do not have. Of course this is subjective ... 

To be honest I don't want to start this before 2.4.  I think
you underestimate the work this would cause.  There are *so
many* places where fvwm assumes that the title height is always
added to the height of the window, not the width.  And don't
forget the WindowShade command.  It was already very difficult
to make it work with bottom titles.  And then the 'rotated font'
utility will require different font handling: at the moment the
height of the title is determined by the height of the tallest
letter, but with rotated font this has to be changed to the width
of the widest letter.  This may not sound much of a change, but
there are many places where this would have to be adapted. It
even appears in the 'Decor' code.  Furthermore all the decorative
subwindows have to be rearranged.

> Whether its a good idea or not, that must be frustrating.

I'm sure I sent some kind of reply :)

> it was always on the condition that it would move into a module.

Bottom titles came nearly for free.  They required very little effort
to code (except adapting the WindowShade command).

> have 3 or 4 users at work using fvwm on slow machines.

I don't understand what you want to say with this. Are you concerned
about performance? If vertical titles are too slow, then don't use
them.

> a feature that will never get used?

I have found one use for bottom titles. I have bound a double click
on the frame to the WindowShade function. Now I can 'ManualHide' :)
my FvwmButtons window: It's at the bottom of the screen and has
'TitleAtBottom' set.  Of course I don't use a title bar ('NoTitle'). 

  *FvwmButtonsGeometry 600x57+0-0

  Style FvwmButtons    NeverFocus, NoTitle, Sticky, WindowListSkip
  Style FvwmButtons    TitleAtBottom
  Style FvwmButtons    HandleWidth 1

  WindowShadeAnimate 6

  AddToFunc ResizeOrRaise
  + C Raise
  + M Raise
  + M Resize
  + D WindowShade toggle
  + D Current (!Shaded) Raise

  Mouse 1 SF    A   Function ResizeOrRaise

> turning the monitor on its side.

I find it fairly readable.

> OK workers, if you want titlebars on the sides of windows with rotated

Not in 2.4.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
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: Dan Espen <[email-masked]>
Date: Fri, 10 Dec 1999 08:11:43 -0500

> I'm sure I sent some kind of reply :)

And I could have missed it.

> > a feature that will never get used?

The machines are slow not only due to slow CPUs, but due to memory
limitations.  Fvwm will probably never use much CPU, but every little
feature chews up another chunk of precious memory.  Once you cross
that magical boundary where you move into constant swapping land,
the machine grinds to a halt.

I can believe that title bars at the bottom didn't really use too much
memory, but I agree with your assessment that titlebars on the side
would not be trivial.

> I find it fairly readable.

OK, I admit, it looks cool.  I just don't think I'd put up with it
for any useful amount of time.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 10 Dec 1999 14:24:09 +0100

> the machine grinds to a halt.

We already have a performance issue with modules.  Communication
over pipes is way too slow, even on a fast machine.  If you want
to know what I mean, start e.g. 30 sticky pagers and then switch
the page.

Bye

Dominik ^_^

---

From: "Paul D. Smith" <[email-masked]>
Date: 10 Dec 1999 10:51:23 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> We already have a performance issue with modules.  Communication
  dv> over pipes is way too slow, even on a fast machine.

Oooh, switching to shared mem!  Now _that_ sounds like cool project to a
OS/system hacker like me (all this X grabbing, etc. is not my cup of tea
:).  Really, it's probably not _that_ hard, either.

I'd have to go back and check out how abstract the current modules
interface is to see whether we could just swap in a new implementation
or not.

Mind you, I'm not saying I'm going to start work in this right now--just
that it sounds fun! :).

PS. Has anyone heard anything else about the problem getting FVWM to
    work on a 64-bit system?  Have we determined that it is actually a
    64-bit long that's causing the problem with the module interface, or
    is it something else?

    I don't have any systems available that do 64-bit long.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Tim Phipps <[email-masked]>
Date: Fri, 10 Dec 1999 16:34:17 +0000

> So, I put the rotated library in my archive for the 2.5.x series ?

How big is it?  An alternative to adding in a library is to do our own. 
Double buffering via a pixmap may be the simplest (it would also fix
some of the flickering I see when moving windows over titlebars)  It
would add extra memory demands on the server but titlebars are fairly
small.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 10 Dec 1999 16:38:54 +0000

> :).  Really, it's probably not _that_ hard, either.

Sounds like a can of worms to me.  The nice thing about pipes is that
they are a reliable comms method that is very portable.  It wouldn't be
hard to implement a FvwmRsh module that ran any module on a remote
machine (why you'd do that I don't know but you could).

With shared memeory you'd have to implement locking and you would
probably have lots of problems with fvwm locking up.  I've also seen
problems with speculative execution on Alpha's breaking lock schemes.

Cheers,
Tim.

---

From: "Paul D. Smith" <[email-masked]>
Date: 10 Dec 1999 12:26:53 -0500

%% Tim Phipps <[email-masked]> writes:

  tp> "Paul D. Smith" wrote:

  >> Oooh, switching to shared mem!  Now _that_ sounds like cool project
  >> to a OS/system hacker like me (all this X grabbing, etc. is not my
  >> cup of tea :).  Really, it's probably not _that_ hard, either.

  tp> Sounds like a can of worms to me.  The nice thing about pipes is
  tp> that they are a reliable comms method that is very portable.  It
  tp> wouldn't be hard to implement a FvwmRsh module that ran any module
  tp> on a remote machine (why you'd do that I don't know but you
  tp> could).

Well, every X implementation I've used in the last 5 years at least uses
shared mem to talk to the local server, and they don't seem to have any
problems with locking or reliability, that I've noticed.

Anyway, I wasn't suggesting requiring it; if the module API is properly
abstracted it could merely be a compile time (or, if you like, even
runtime) option.

Again, though, I'm not running out to implement it.  I actually feel the
module interface is surprisingly fast for how low-tech it is--but I
don't push it much; I don't use Icon* or WinList or anything, just
FvwmAuto, FvwmButtons, FvwmPager, and some FvwmForm.  _If_ we started
abstracting out decorations into a module, etc. like we've discussed
before we may need to start thinking more carefully about module
interface performance.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 10 Dec 1999 20:11:34 +0200

> Bottom titles came nearly for free.  They required very little effort

I would not underestimate your "very little effort".

> to code (except adapting the WindowShade command).

Here is a new bug, which can be demonstrated using WindowShade.
  1) Shade a window MyName with a top title
  2) Execute: Style MyName TitleOnBottom  (no changes to a shaded window)
  3) Unshade it (it's funny)

The right fix is: a shaded window should change its position in step 2).

Regards,
Mikhael.

---

From: Ben Winslow <[email-masked]>
Date: Fri, 10 Dec 1999 15:50:08 -0500

On Fri, Dec 10, 1999 at 10:51:23AM -0500, Paul D. Smith wrote:
# Received: from BlackHole.RainNet.Org ([email-masked] [192.168.1.3])
# 	by Portal.RainNet.Org (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA25291
# 	for <[email-masked]>; Fri, 10 Dec 1999 10:53:10 -0500
# Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35])
# 	by BlackHole.RainNet.Org (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA06751
# 	for <[email-masked]>; Fri, 10 Dec 1999 10:53:06 -0500
# Received: from sina.hpc.uh.edu ([email-masked] [129.7.3.5])
# 	by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id JAB13657;
# 	Fri, 10 Dec 1999 09:52:59 -0600 (CST)
# Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 10 Dec 1999 09:53:04 -0600 (CST)
# Received: from karazm.math.uh.edu (karazm.math.uh.edu [129.7.128.1])
# 	by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id JAA12953
# 	for <[email-masked]>; Fri, 10 Dec 1999 09:52:51 -0600 (CST)
# Received: from lobster.baynetworks.com (ns3.BayNetworks.COM [192.32.253.3])
# 	by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id JAA29262
# 	for <[email-masked]>; Fri, 10 Dec 1999 09:52:27 -0600 (CST)
# Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84])
# 	by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id KAA03572
# 	for <[email-masked]>; Fri, 10 Dec 1999 10:55:02 -0500 (EST)
# Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
# 	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA15549
# 	for <[email-masked]>; Fri, 10 Dec 1999 10:46:59 -0500 (EST)
# Received: from lemming.engeast (lemming [192.32.148.86])
# 	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
# 	id KAA13215; Fri, 10 Dec 1999 10:51:24 -0500
# 	for <[email-masked]>
# Received: by lemming.engeast (SMI-8.6/SMI-SVR4)
# 	id KAA01354; Fri, 10 Dec 1999 10:51:23 -0500
# To: [email-masked]
# Subject: Re: Rotated Font
# References: <[email-masked]> <[email-masked]> <[email-masked]>
# Reply-To: [email-masked]
# From: "Paul D. Smith" <[email-masked]>
# In-Reply-To: Dominik Vogt's message of "Fri, 10 Dec 1999 14:24:09 +0100"
# Reply-To: [email-masked]
# Date: 10 Dec 1999 10:51:23 -0500
# Message-ID: <[email-masked]>
# User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5
# MIME-Version: 1.0
# Content-Type: text/plain; charset=us-ascii
# Sender: [email-masked]
# Precedence: list
# X-Majordomo: 1.94.jlt7
# Content-Length: 1561
# Lines: 29
# 
# %% Dominik Vogt <[email-masked]> writes:
# 
#   dv> We already have a performance issue with modules.  Communication
#   dv> over pipes is way too slow, even on a fast machine.
# 
# Oooh, switching to shared mem!  Now _that_ sounds like cool project to a
# OS/system hacker like me (all this X grabbing, etc. is not my cup of tea
# :).  Really, it's probably not _that_ hard, either.
# 
# I'd have to go back and check out how abstract the current modules
# interface is to see whether we could just swap in a new implementation
# or not.
# 
# Mind you, I'm not saying I'm going to start work in this right now--just
# that it sounds fun! :).
# 
# PS. Has anyone heard anything else about the problem getting FVWM to
#     work on a 64-bit system?  Have we determined that it is actually a
#     64-bit long that's causing the problem with the module interface, or
#     is it something else?
# 
#     I don't have any systems available that do 64-bit long.
# 
# -- 
# -------------------------------------------------------------------------------
#  Paul D. Smith <[email-masked]>         Network Management Development
#  "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
# -------------------------------------------------------------------------------
#    These are my opinions---Nortel Networks takes no responsibility for them.
# --
# 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]
egad, I need to have mutt trim my headers.  Anyway, if you feel like
experimenting, put "#define long long long" in fvwm.h and fvwmlib.h, and
*theoretically* this will emulate the same effect...

-- 
Ben Winslow           /   [email-masked]
bluecherry internet   /   http://www.bluecherry.net
|Rain| @ IRC          /   anynet: irc.anynet.org

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 11 Dec 1999 00:02:14 +0100

> The right fix is: a shaded window should change its position in step 2).

Nope, it's not a bug. I thought about it and decided for me that
it's less confusing to keep the shaded titles in place instead
of warping them to their new locations (= confusing).  Of course
you may disagree.  However, I don't think it's worth the effort
to do anything about it.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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, 11 Dec 1999 09:40:54 +0100

> Not in 2.4.

Ok, I perfectly understand. I think that everybody want to see 2.4 to appear
as fast as possible. fvwm had mad so many progresses since 2.2.
If Linus decides that the next kernel series is 2.9, I think fvwm is ready ;)

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 11 Dec 1999 09:43:26 +0100

>     I don't have any systems available that do 64-bit long.

The only thing I can do here is to make test with the snapshots.
Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 11 Dec 1999 09:47:09 +0100

> a feature that will never get used?

Ok, the main interest of side title bar is its used with small screen
(i.e., 12'' or less which do 800x600). There are a category of users 
that will always have such screens: the laptop users (I'm one). 
Since Linux (and BSD) become popular, I think that this category is 
and will become a large one (see os.comp.linux.portable). More and more applications and environments forget poor screen, I do not want fvwm 
do that.
 
> turning the monitor on its side.

I tried wmx/wm2 and titles are readable on my 12'' 800x600 screen. 
Moreover, the look will be I think pretty. But the main point
is not the font rotation but the side title bar.

Olivier

PS: this mail was written one day ago (but I lost my link with my ISP
during 24 hours). I send it as it is anyway.

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 11 Dec 1999 09:15:59 +0100

Tim Phipps wrote:
> How big is it?

I think now that an answer have to wait the 2.5.x series, but since
every thing is their ...

[olivier@snoopy libs]$ ll Rotated.c
-rw-r--r--   1 olivier  users       16186 nov 22 13:55 Rotated.c
[olivier@snoopy libs]$ ll libfvwm.a
-rw-r--r--   1 olivier  users      848414 déc  9 21:23 libfvwm.a
[olivier@snoopy FvwmIdent]$ ll FvwmIdent.c (Vertical patch)
-rw-r--r--   1 olivier  users       24412 nov 23 11:33 FvwmIdent.c
[olivier@snoopy FvwmIdent]$ ll FvwmIdent
-rwxr-xr-x   1 olivier  users      354840 déc  9 21:40 FvwmIdent
[olivier@snoopy FvwmIdent]$ ps xm | grep FvwmIdent (Vertival patch)
 PID TTY MAJFLT MINFLT   TRS   DRS  SIZE  SWAP   RSS  SHRD   LIB  DT COMMAND
 585  ?     209     27    40   728   768     0   768   636     0  33 

Now I put Rotated.c in my archive and remove the Vertical Ident patch:

[olivier@snoopy libs]$ ll libfvwm.a
-rw-r--r--   1 olivier  users      796818 déc 11 08:56 libfvwm.a
[olivier@snoopy FvwmIdent]$ ll FvwmIdent.c
-rw-rw-rw-   1 olivier  users       23454 déc 11 08:50 FvwmIdent.c
[olivier@snoopy FvwmIdent]$ ll FvwmIdent
-rwxr-xr-x   1 olivier  users      307233 déc 11 08:53 FvwmIdent
[olivier@snoopy FvwmIdent]$ ps xm | grep FvwmIdent	
 PID TTY MAJFLT MINFLT   TRS   DRS  SIZE  SWAP   RSS  SHRD   LIB  DT COMMAND
 1347 ?     222     24    28   704   732     0   732   612     0  30 

Do not know if all this numbers say something ... Note that the lib
is really easy to use, here the Rotated.h doc ("fvwm" version):

/* ---------------------------------------------------------------------- */

/*
 * Library for rotated a font and use it
 * dpy         : the display
 * fontname    : the name of a X font
 * angle       : rotation angle in degree (e.g., for book in a library: 
 *               -90.0 for "english" and 90.0 for "french")
 * rotfont     : the rotated font
 * drawable    : the window on which we draw the rotated string
 * gc          : the graphic context
 * x,y         : origin of the rotated string in the drawable
 * string      : character string to rotate and display
 * lenght      : number of characters in the string argument
 * align       : a logic for placing string (see below)
 */

/* *** Load the rotated version of a given font *** */
extern XRotFontStruct *XRotLoadFont(Display *dpy, char *fontname, float angle);

/* *** Free the resources associated with a rotated font *** */
extern void XRotUnloadFont(Display *dpy, XRotFontStruct *rotfont);

/* *** Return the width of a string *** */
extern int XRotTextWidth(XRotFontStruct *rotfont, char *string, int lenght);

/* *** A front end to XRotPaintString : mimics XDrawString *** */
extern void XRotDrawString(Display *dpy, XRotFontStruct *rotfont, 
			   Drawable drawable, GC gc, int x, int y, 
			   char *string, int lenght);

/* *** A front end to XRotPaintAlignedString : uses XRotDrawString *** */
extern void XRotDrawAlignedString(Display *dpy, XRotFontStruct *rotfont, 
				  Drawable drawable, GC gc, int x, int y, 
				  char *string, int align);

/* ---------------------------------------------------------------------- */

/* T: top of the rotated string
 * M: midle of the rotated string
 * B: bottom of the rotated string
 * CENTER: center of the rotated string
 * LEFT:   left   ""
 * RIGHT:  right  "" 
 * For example we have a 20x200 window and a Rotfont of -/+90.0 and we want
 * that the string to be displayed to by CenterJustified then
 * use:
 * XRotDrawAlignedString(...,10 ,100, string*, MCENTRE) 
 * If you want to upJustify use (..., 10, 2, MLEFT) with -90.0 
 * If you want to DownJustify use (..., 10, 198, MLEFT) with -90.0 */

#define TLEFT	 	 1
#define TCENTRE	 	 2
#define TRIGHT	 	 3
#define MLEFT	 	 4
#define MCENTRE	 	 5
#define MRIGHT	 	 6
#define BLEFT	 	 7
#define BCENTRE	 	 8
#define BRIGHT	 	 9

#endif 

> An alternative to adding in a library is to do our own.