Subject: FVWM: feature request of old: WindowShade

From: Liem Bahneman <[email-masked]>
Date: Fri, 6 Oct 1995 08:47:05 -0700 (PDT)

A long while ago (1.* days) I suggested this feature, but I forget how 
the response was. It's a *cough* mac System 7.5 feature that I thought 
was really neat, instead of iconfiying the window, you just hide the 
window but leave the titlebar, like a, well, Window Shade. 

Seems like all the code is already in place (seems to me, anyways), 
instead of hiding all the wm stuffs, leave the titlebar there. 

I'm not sure if anyone else appreciates this feature, but sometimes icons 
are just so impractical and small. 

- liem

============================================================================
Liem Bahneman                                                 [email-masked]
System Administrator				  http://www.ssc.com/~roland
Specialized Systems Consultants/Linux Journal     Seattle, WA (206) 782-7733

--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 6 Oct 1995 13:23:56 -0400

>>>>> "Liem" == Liem Bahneman <[email-masked]> writes:

Liem> A long while ago (1.* days) I suggested this feature, but I
Liem> forget how the response was. It's a *cough* mac System 7.5
Liem> feature that I thought was really neat, instead of iconfiying
Liem> the window, you just hide the window but leave the titlebar,
Liem> like a, well, Window Shade.

Liem> Seems like all the code is already in place (seems to me,
Liem> anyways), instead of hiding all the wm stuffs, leave the
Liem> titlebar there.

Liem> I'm not sure if anyone else appreciates this feature, but
Liem> sometimes icons are just so impractical and small.

I recall this request.  I think it sounds interesting, so I'll add it
to my TO-DO list.  I wonder if this could be done as a module (which
is how I'd prefer it to be implemented)?  Perhaps after some of the
additional module communication information that I mentioned in an
earlier note (sending titlebar window ids) is added.

Chuck

*******************************************************************************
Charles K. Hines
IBM Logic Synthesis developer [BooleDozer (TM)]
and Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

Internet e-mail:     [email-masked]

IBM Internal e-mail: [email-masked]   (preferred from workstation)
                     HINESC at FISHKILL       (preferred from mainframe)
                     HINESC at FSHVMFK1       (discouraged, but I'll get it)

*******************************************************************************
 "dis ting could have possabiwities if I put my twisted widdle mind to it!"
                                                        - Bugs Bunny

 "I have a paper plate in my head because they were all out of the metal ones"
                                                        - Rick Overton
*******************************************************************************
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Elan Feingold <[email-masked]>
Date: Fri, 6 Oct 1995 15:19:53 -0400

> window but leave the titlebar, like a, well, Window Shade. 

I like this idea!

A quick bug report: The titles in the title bars of the windows do not
change ever.  For example, XEmacs prints in the title the name of the
buffer you are editing.  This doesn't change, unless you restart fvwm.

Best regards, 

-Elan

P.S. Here's a picture of my hacked up fvwm -- I want to generalize the
patches and submit them -- in my .fvwmrc I have:

ButtonStyle 2 Pixmap Normal:obm_close_95 Pressed:obm_closed_95
ButtonStyle 4 Pixmap Normal:obm_zoom_95 Pressed:obm_zoomd_95 Active:maxwin95.xpm
ButtonStyle 6 Pixmap Normal:obm_reduce_95 Pressed:obm_reduced_95
ButtonStyle 1 Pixmap Normal:win95.xpm

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 6 Oct 1995 16:31:30 -0400

>>>>> "Elan" == Elan Feingold <[email-masked]> writes:

>> window but leave the titlebar, like a, well, Window Shade.

Elan> I like this idea!

Elan> A quick bug report: The titles in the title bars of the windows
Elan> do not change ever.  For example, XEmacs prints in the title the
Elan> name of the buffer you are editing.  This doesn't change, unless
Elan> you restart fvwm.

You must be using pl34.  Pick up pl37, available shortly.

Elan> P.S. Here's a picture of my hacked up fvwm -- I want to
Elan> generalize the patches and submit them -- in my .fvwmrc I have:

Elan> ButtonStyle 2 Pixmap Normal:obm_close_95 Pressed:obm_closed_95
Elan> ButtonStyle 4 Pixmap Normal:obm_zoom_95 Pressed:obm_zoomd_95 Active:maxwin95.xpm
Elan> ButtonStyle 6 Pixmap Normal:obm_reduce_95 Pressed:obm_reduced_95
Elan> ButtonStyle 1 Pixmap Normal:win95.xpm

I like the idea of the Pixmaps for buttons, but Xpm's (and general
look) you picked kinda scare me...

Will your patches use a TitleStyle type setup that would control
justification, font,  and Raised/Flat/Sunk (border) type things?

Chuck

---

From: Elan Feingold <[email-masked]>
Date: Fri, 6 Oct 1995 16:57:18 -0400

> You must be using pl34.  Pick up pl37, available shortly.

Will do -- thanks.

 > look) you picked kinda scare me...

:) My rationale is that above all, I'd like consistency.  I don't want
to have completely different look and feel every time I reboot between
Win95 and Linux.  And I happen to find the Win95 window manager
aesthetically pleasing (and of course completely brain-dead compared
to fvwm :)

 > justification, font,  and Raised/Flat/Sunk (border) type things?

I will do everything as generally as I can, so just like you can
specify MenuStyle of fvwm or Motif, I would add Win95.  I have an
additional ButtonStyle called Icon, which simply scales the window's
icon down to fit in a titlebar button.

For the title-bar, I would expect something similar, as you mention
above.

Best regards, 

-Elan

 > and Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

I've been studying Tae Kwon Do for about 4 years...
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Jean-Marc Lasgouttes <[email-masked]>
Date: Mon, 9 Oct 1995 14:12:49 +0100

Elan> P.S. Here's a picture of my hacked up fvwm -- I want to
    Elan> generalize the patches and submit them -- in my .fvwmrc I
    Elan> have:

    Elan> ButtonStyle 2 Pixmap Normal:obm_close_95
    Elan> Pressed:obm_closed_95 ButtonStyle 4 Pixmap
    Elan> Normal:obm_zoom_95 Pressed:obm_zoomd_95 Active:maxwin95.xpm
    Elan> ButtonStyle 6 Pixmap Normal:obm_reduce_95
    Elan> Pressed:obm_reduced_95 ButtonStyle 1 Pixmap Normal:win95.xpm

Instead of making fvwm able to have a bazillion of user interface,
would it be possible to have modules that handle windows decoration
and menus ? If the inter-modules communication is not too slow, it
would allow to have a win95 module, a macOS module, a warp module or
whatever, and keeping fvwm core small. The current window decorations
and menus could be kept as default, but possibly overridden by some
module routines.

If it is feasible in terms of speed, I'd rather see that than a lot of
new functions.

Jean-Marc.

---

From: <[email-masked]> (Charles Hines)
Date: Mon, 9 Oct 1995 09:39:10 -0400

>>>>> "Jean-Marc" == Jean-Marc Lasgouttes <[email-masked]> writes:

Jean-Marc> Instead of making fvwm able to have a bazillion of user
Jean-Marc> interface, would it be possible to have modules that handle
Jean-Marc> windows decoration and menus ? If the inter-modules
Jean-Marc> communication is not too slow, it would allow to have a
Jean-Marc> win95 module, a macOS module, a warp module or whatever,
Jean-Marc> and keeping fvwm core small. The current window decorations
Jean-Marc> and menus could be kept as default, but possibly overridden
Jean-Marc> by some module routines.

Jean-Marc> If it is feasible in terms of speed, I'd rather see that
Jean-Marc> than a lot of new functions.

It's funny you should bring this up.  I was wondering about that
myself.  I don't want to bloat fvwm, so any new things that come up
I've been suggesting be implemented in modules if at all possible.

I hadn't said anything about this specific instance, because I think
that the Pixmap buttons addition & the TitleStyle stuff need to be in
the main executable, but wasn't sure about the Win95 MenuStyle.

I'd prefer it (Win95 menus) as a module, but it would probably be too
slow.  Unless the module could be kept running constantly instead of
being run when needed...  Perhaps if modules could override built in
commands (ie Popup and Menu) to send messages to the already running
modules, then it might be fast enough.

Chuck

---

From: Jean-Marc Lasgouttes <[email-masked]>
Date: Mon, 9 Oct 1995 14:49:22 +0100

>>>>> "Chuck" == Charles Hines <[email-masked]> writes:

    Jean-Marc> Instead of making fvwm able to have a bazillion of user
    Jean-Marc> interface, would it be possible to have modules that
    Jean-Marc> handle windows decoration and menus ? 

    Chuck> It's funny you should bring this up.  I was wondering about
    Chuck> that myself.  I don't want to bloat fvwm, so any new things
    Chuck> that come up I've been suggesting be implemented in modules
    Chuck> if at all possible.
    [...]

    Chuck> I'd prefer it (Win95 menus) as a module, but it would
    Chuck> probably be too slow.  Unless the module could be kept
    Chuck> running constantly instead of being run when needed...
    Chuck> Perhaps if modules could override built in commands (ie
    Chuck> Popup and Menu) to send messages to the already running
    Chuck> modules, then it might be fast enough.

That's what I had in mind. Launching a module each time would be to
expensive in terms of time. But sending a message to a module telling
'draw window number 12345' should be fast enough. I guess that new
messages should be added to fvwm to be able to handle this
mechanism. Then, those who want could design a GEM UI or a Apple Lisa
UI as they which :-)

Jean-Marc.

---

From: Elan Feingold <[email-masked]>
Date: Mon, 9 Oct 1995 10:39:24 -0400

> modules, then it might be fast enough.

When I was thinking about writing a Start bar for fvwm (a la Win95's
start bar), I thought: `this has got to be a module'.  But then I
realized that it would primarily be using (a) Pixmaps from the icons,
and (b) Menus.  Using its own menu code would be wasteful, since 99%
of it would be identical with fvwm's menus, and I would hate for it to
have its own pixmaps, when they are in common with fvwm's (unless
somehow, fvwm told the module about the pixmaps).

I still think it should be a module, but I also think the issues
remain.  The counter argument is that the start bar is simply a type
of menu just like the pop-ups that exist in fvwm today.

As far as Menu styles, the MenuStyle Win95 was simply based on the
existing MenuStyle Motif, MenuStyle Fvwm.  I think that once a core
amount of functionality has been agreed on for fvwm (e.g. title bar &
title buttons, borders, pop-up menus, etc.), then these should be
customizable via Style directives.  If the code were written in an OO
programming language, this would be probably easier than it is today,
and it would allow for a cleaner separation of these styles
(i.e. class MacTitleBar : public TitleBar) (but this is just my
opinion :)

On another note, I'm wondering if many of you out there use Xnest for
debugging fvwm.  I've found it to be pretty useful when working on
fvwm.  For those who aren't acquainted with this program, it's an X-
Server-in-a-window.  You then invoke fvwm as `fvwm -display :1' and
you can test the window manager without fear of crashing your main X
Server or disrupting your session.

Best regards, 

-Elan

---

From: Jean-Marc Lasgouttes <[email-masked]>
Date: Mon, 9 Oct 1995 17:00:49 +0100

>>>>> "Elan" == Elan Feingold <[email-masked]> writes:

    Elan> When I was thinking about writing a Start bar for fvwm (a la
    Elan> Win95's start bar), I thought: `this has got to be a
    Elan> module'.  But then I realized that it would primarily be
    Elan> using (a) Pixmaps from the icons, and (b) Menus.  Using its
    Elan> own menu code would be wasteful, since 99% of it would be
    Elan> identical with fvwm's menus, and I would hate for it to have
    Elan> its own pixmaps, when they are in common with fvwm's (unless
    Elan> somehow, fvwm told the module about the pixmaps).

The code in fvwm/menu.c can be divided between

  1/ code that generates and destroys menus in memory;
  2/ code to display menus.

Obviously, only (a part of) 2/ has to be rewritten. If it is possible
for fvwm to pass a complete menu data structure to a module when it is
modified, then 1/ could be kept in fvwm/, along with some additionnal
communication code. If this is not possible, 1/ could be at least
moved to fvwmlib to avoid source duplication, if not code bloat (which
could be avoided with a shared library, but since libfvwm is so
small...)

Then the code of 2/ could be duplicated from fvwm/menus.c. The same
holds for drawing windows, since positionning the title and using
xpm's is not enough to emulate the look and feel of a window manager. 

Now, if we can come up with a relatively simple definition of menu
appearance that can be parameterized (for example, in terms of color
and shadow thickness for menus themselves, selected item, separators,
submenu arrows, etc.), then some general code could be written and an
UI would just be a set of parameters (Just have to do 'Read Win95Menus'
to enable it). Thus, no specific code would be hardcoded in fvwm for
these menus.

    Elan> I still think it should be a module, but I also think the
    Elan> issues remain.  The counter argument is that the start bar
    Elan> is simply a type of menu just like the pop-ups that exist in
    Elan> fvwm today.

The start bar is also, if I am not mistaken, an icon manager that
shows all (iconified ?) applications. It could be programmed as such
(perhaps derived from FvwmIconBox) and call fvwm do displays
menus. Then, if you have a module that can display win95-like menus,
they will be shown as such. Of course, the same module could be both
an icon manager and an UI module.

    Elan> As far as Menu styles, the MenuStyle Win95 was simply based
    Elan> on the existing MenuStyle Motif, MenuStyle Fvwm.  I think
    Elan> that once a core amount of functionality has been agreed on
    Elan> for fvwm (e.g. title bar & title buttons, borders, pop-up
    Elan> menus, etc.), then these should be customizable via Style
    Elan> directives.  If the code were written in an OO programming
    Elan> language, this would be probably easier than it is today,
    Elan> and it would allow for a cleaner separation of these styles
    Elan> (i.e. class MacTitleBar : public TitleBar) (but this is just
    Elan> my opinion :)

Yes, but not every one want a large fvwm binary that can handle 45
different user interfaces. You like win95 look, but assume that
someone wants to add windows 2.0 or even twm ; the code will shortly
become very difficult to maintain. I think that the mwm style has some
reasons to be in the core, since mwm is typically a unix window
manager (except for Geos on PC, but this is a different
problem...). Moreover, fvwm tries to emulate mwm for Motif programs
that expect it to be there. The win95 style is more like an aesthetic
add-on (which I'd really like to see, in fact :-).

The example of Geos is not really innocent. In this OS, all the UI
stuff is located in a module (a geode, in geospeak). If you change this
module, the whole user interface is changed (not only the menus or
window decorations, but all dialogs, scrollbars, etc.). I have not
seen it myself, but a MacIntosh interface and a windows 2.0 interface
have been demonstrated for various versions of Geos.

If this is not too difficult in terms of coding and/or to slow, I'd
like to see fvwm take this direction. But, well, I don't really know C
or Xlib, so I won't do the coding myself. So I guess that people that
do the *real* work should be free to choose what they want to do :-)

Jean-Marc.