Subject: TITLE ICONS/Fvwm95

From: Don Mahurin <[email-masked]>
Date: Sun, 02 Jun 1996 08:01:43 -0400

Hi all,

Is someone out there working on putting TITLE-ICON SUPOORT in FVWM?(Like
there is in FVWM95)

The reason for asking is because this is what makes the two incompatible
as far as modules.

For example, I have modified FvwmWinList in Fvwm95 to support the Title
Icons, like the TaskBar and added the ability to Reflect what is on your
CURRENT DESK only.  This will not compile on Fvwm2.

If no-one else wants to do this, and no one has big objections to it, I
could maybe do it.

This whole thing leads to the bigger issue of the Fvwm - Fvwm95 split.
Are they really that different that we cannot combine them.  NO.

Here what I see the differences are right now:

Fvwm95 has no corner decorations.  Non issue, Fvwm2 can do this already
(Handle width = 0, Border width = 5)

Fvwm95 has no inner frame shadows, to make it appear like the contents
are seting on some Tile, not inset into something.  I have found where
the inner shadows are in the code, though the outer shadows seam to be
different too.

The only thing that changes colors on Focus is the title bar.
This could some option, or specify the Focused/unfocused title bar
colors separately.

And yes the TITLE-ICONS. These are mini icons that are specified with an
application.  They replace the upper left Window menu button, and are
beside the name in FvwmTaskbar and FvwmWinList(next release).  You can
have mini-icons in Menus too.  In FvwmButtons too eventually.

Ideas, Comments.
Don Mahurin
[email-masked]
http://www.donet.com/dmahurin
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Jason L Tibbitts III <[email-masked]>
Date: Sun, 02 Jun 1996 16:51:33 -0500

>>>>> "DM" == Don Mahurin <[email-masked]> writes:

DM> This whole thing leads to the bigger issue of the Fvwm - Fvwm95 split.
DM> Are they really that different that we cannot combine them.  NO.

The last thing we need is yet another split.  There have been so many
(Bowman, fvwm95, others I can't remember) and of course fvwm was a split of
its own.  A bunch of diverging development streams just slows down the
whole effort.

Now is of course not the time to try to combine development.  Now is the
time to say "enough with beta versions of fvwm2" and get it out the door.
Chuck is almost ready and we're here to do the testing on various
platforms.

After 2.0 release I think the next thing on the list is the style flag
rewrite.  Once that is finished and debugged it's time to think about
fvwm95 and new features.  I think it's premature to do anything else,
really, until a release is made and the style flags are redone.

The issue of whether or not to incorporate all of those extra goodies is up
to Chuck.  I think that generalizing things like title and border
appearance even further can't hurt and might not bloat things a bit.
Pixmaps in the title bar can't be more complex than the current system,
though I agree with Chuck that it's not fvwm's place to do any kind of
scaling or image manipulation.

 - J<

---

From: <[email-masked]> (Charles Hines)
Date: Mon, 3 Jun 1996 17:09:07 -0400

>>>>> "Don" == Don Mahurin <[email-masked]> writes:
>>>>> "Jason" == Jason L Tibbitts <[email-masked]> writes:

Don> Hi all,

Howdy Don.

Don> Is someone out there working on putting TITLE-ICON SUPOORT in
Don> FVWM?(Like there is in FVWM95)

Nope.  Or if they are it's most likely wasted effort, since I don't
think fvwm needs this and said so in the past, which is one of the
reasons that they hacked out fvwm95.

I don't mean to sound overly negative in this note, but most everyone
here already knows my reasoning.  I'll put a few here again though,
just for grins:

  - Keeping fvwm relatively lightweight and fast is a big thing for
    me.  New functionality is also good, but must be weighed against
    this to prevent bloating.  A new look provides no new
    functionality, but I am willing to bend a little sometimes, for
    example the pixmap buttons, if the code isn't too much.
  - Fvwm doesn't need to be able to look like a bunch of different
    window managers, and especially not win95 (after all, we're
    dealing with UNIX, a REAL operating system).  Granted, a lot of
    people are used to that look and feel, but I think if small
    changes can be made to fvwm to ensure that similiar keystrokes can
    be bound, that is more important and more than sufficient.
  - I don't care for anything winXX.
  - I wouldn't want to get sued by you-know-who for infringement upon
    their look and feel. :)
  - I've finially resigned myself to the fact that I can't please
    everyone, not even myself, no matter how much I'd like to.

....
Don> This whole thing leads to the bigger issue of the Fvwm - Fvwm95
Don> split.  Are they really that different that we cannot combine
Don> them.  NO.

Only the fact that I feel that a lot of the differences don't need to
be merged in, and that there are more important things to work on,
which again is what caused them to hack out fvwm95.

Certain concepts from fvwm95 could perhaps be adopted in fvwm though.

Jason> The last thing we need is yet another split.  There have been
Jason> so many (Bowman, fvwm95, others I can't remember) and of course
Jason> fvwm was a split of its own.  A bunch of diverging development
Jason> streams just slows down the whole effort.

Well, if people want to create a new window manager based on fvwm
(like Bowman did, with a change in name and docs), that's fine.  After
all, that is how fvwm started (as you noted).  Continuously updating
one or the other to stay in sync would be a detriment though, I
believe.

Jason> Now is of course not the time to try to combine development.
Jason> Now is the time to say "enough with beta versions of fvwm2" and
Jason> get it out the door.  Chuck is almost ready and we're here to
Jason> do the testing on various platforms.

I fully agree.  It's been beta way too long.

Jason> After 2.0 release I think the next thing on the list is the
Jason> style flag rewrite.

That is definitely the next thing on my plate after 2.1.0 gets
released.  I may need to make a few bugfix releases to that, but then
the next beta after that will probably be numbered 2.2.0, due to the
amount of code change needed for the style flags fixes...

Jason> Once that is finished and debugged

Which is probably going to take a little while...

Jason> it's time to think about fvwm95 and new features.  I think it's
Jason> premature to do anything else, really, until a release is made
Jason> and the style flags are redone.

Yup.  There are only a couple of new (relatively simple) things that
are going to be in 2.0.43, and I'd like to make the one after that be
2.1.0 (nothing new over 2.0.43 but bug & doc fixes).

Don> Here what I see the differences are right now:

Don> Fvwm95 has no corner decorations.  Non issue, Fvwm2 can do this already
Don> (Handle width = 0, Border width = 5)

Actually HandleWidth means "width of border if it has handles" and
BorderWidth means "width of border if it doesn't have handles".  I
don't think that the distinction makes much sense and that it might be
better to just have one BorderWidth value.  Does anyone out there
actually use different values for these?  I guess one way to find out
would be to remove it... :)

Anyways, fvwm can do it - the style option NoHandles is actually what
you use to remove the resize handles from the windows.

Don> Fvwm95 has no inner frame shadows, to make it appear like the
Don> contents are seting on some Tile, not inset into something.  I
Don> have found where the inner shadows are in the code, though the
Don> outer shadows seam to be different too.

This is probably only a few lines in RelieveWindow and RelieveParts,
which I might be willing to make an option for.

Don> The only thing that changes colors on Focus is the title bar.
Don> This could some option, or specify the Focused/unfocused title
Don> bar colors separately.

I was thinking about making an additional option for this, since I
know some people who only change the font color to indicate focus
change, changing the title bar only might be nice too, if it doesn't
take too much code & resources to do so.  I haven't investigated this
yet.

Don> And yes the TITLE-ICONS. These are mini icons that are specified with an
Don> application.  They replace the upper left Window menu button, and are
Don> beside the name in FvwmTaskbar and FvwmWinList(next release).  You can
Don> have mini-icons in Menus too.  In FvwmButtons too eventually.

As stated previously, I really don't want that in there...

Jason> The issue of whether or not to incorporate all of those extra
Jason> goodies is up to Chuck.

Do not adjust your sets...I have taken control... :)

Jason> I think that generalizing things like title and border
Jason> appearance even further can't hurt and might not bloat things a
Jason> bit.

No, it shouldn't be too bad, but that still isn't a reason to go
overboard with it.  A few of little changes can add up to a lot.  But
as I mentioned above, I am willing to look into a few of them
(probably enough to make most people happy).  Some of them would
should probably be global options instead of Style options though, to
help save on memory.  Again, investigations will occur...

Jason> Pixmaps in the title bar can't be more complex than the current
Jason> system,

Do you mean Andrew's patch for the focused & unfocused title bar
pixmaps, or the mini-icon as button one?  The former might not be too
bad, but I'm still thinking about it...

Jason> though I agree with Chuck that it's not fvwm's place to do any
Jason> kind of scaling or image manipulation.

Definitely.

Well, time for me to go.
Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Jason L Tibbitts III <[email-masked]>
Date: 03 Jun 1996 17:35:56 -0500

>>>>> "CH" ==   <[email-masked]>,
>>>>> "Don" == Don Mahurin <[email-masked]>,
>>>>> "Jason" == Jason L Tibbitts <[email-masked]>:

Don> And yes the TITLE-ICONS. These are mini icons that are specified with
Don> an application.  They replace the upper left Window menu button, and
Don> are beside the name in FvwmTaskbar and FvwmWinList(next release).  You
Don> can have mini-icons in Menus too.  In FvwmButtons too eventually.

CH> As stated previously, I really don't want that in there...

Well, if you allow title-bar buttons to be set on a per-window basis and
the winlist module can get at the buttons then you have the intended
behavior (unless I'm confused about something).  Allowing pixmaps instead
of the current vectorized buttons is just icing on the cake.

I can easily see how having some easy means of identifying what a window
contains would be useful; the icon texts for my xterms contain the current
working directory, not "XTerm".  A little icon besides that would make it a
bit easier when I have twenty windows open.

Jason> I think that generalizing things like title and border appearance
Jason> even further can't hurt and might not bloat things a bit.

CH> No, it shouldn't be too bad, but that still isn't a reason to go
CH> overboard with it.  A few of little changes can add up to a lot.

I was thinking that after you reach a certain level of complexity (piles of
window decoration parameters) it becomes worthwhile to generalize things.
Say you assign each decoration a number and instead of looking in some
bizarre variable you use an array reference.  At that point it becomes
trivial (and essentially free) to replace every hardcoded border and shadow
width with a lookup.  You lose some ease in configurability, though,
because you have to remember numbers instead of names.  Hooray for #define,
I suppose.

CH> Some of them would should probably be global options instead of Style
CH> options though, to help save on memory.

Does anyone really make some windows look vastly different than others?  I
can see having different colors, but not different border widths and
shading.

CH> Do you mean Andrew's patch for the focused & unfocused title bar
CH> pixmaps, or the mini-icon as button one?  The former might not be too
CH> bad, but I'm still thinking about it...

I meant that allowing pixmaps as title-bar buttons has got to be easier
than the vector-style method fvwm uses now.  Then again, the vector method
is nice because the buttons can be scaled....

 - J<

---

From: Dave Goldberg <[email-masked]>
Date: Tue, 04 Jun 1996 09:36:55 -0400

>>>>> Jason L Tibbitts writes:

> Does anyone really make some windows look vastly different than
> others?  I can see having different colors, but not different border
> widths and shading.

I'm not sure what constitutes vastly different, but from what I've
seen of some snapshot's it's not uncommon to set a smaller borderwidth
(I use 0) for modules like FvwmButtons and FvwmIconBox.  I do this
since I generally have those windows exactly where I want them so I
don't need anything to grab onto for moves or resizes etc.  I also
remove the title bar from them.

--
Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: [email-masked]

---

From: Kai Grossjohann <[email-masked]>
Date: 04 Jun 1996 16:15:44 +0200

>>>>> On Tue, 04 Jun 1996 09:36:55 -0400, Dave Goldberg
>>>>> <[email-masked]> said:

  Dave> I'm not sure what constitutes vastly different, but from what
  Dave> I've seen of some snapshot's it's not uncommon to set a
  Dave> smaller borderwidth (I use 0) for modules like FvwmButtons and
  Dave> FvwmIconBox.

Yes, I too have a number of windows that are sticky.  They include
xpostit, xclock, xload, xbiff, xmultibiff, timex and contool.  Also,
there are FvwmPager and FvwmWinList.  All of these have no decoration
at all.  All other windows have the same appearance, though: same
border width, same color (but different highlight color, of course).

kai
-- 
Life is hard and then you die.

---

From: <[email-masked]> (Charles Hines)
Date: Tue, 4 Jun 1996 09:31:50 -0400

Jason> Well, if you allow title-bar buttons to be set on a per-window
Jason> basis and the winlist module can get at the buttons then you
Jason> have the intended behavior (unless I'm confused about
Jason> something).

No, you aren't confused, that's what I don't want to do.  Making the
button styles per window attributes will add quite a bit to each
window structure.  I'd rather keep that global.

Jason> Allowing pixmaps instead of the current vectorized buttons is
Jason> just icing on the cake.

Pixmaps can currently be used instead of the regular buttons, but they
are global values.

Jason> I can easily see how having some easy means of identifying what
Jason> a window contains would be useful; the icon texts for my xterms
Jason> contain the current working directory, not "XTerm".  A little
Jason> icon besides that would make it a bit easier when I have twenty
Jason> windows open.

So, perhaps a way to allow the icons to be drawn inside the icon text
box (much like the menus) could be made.  It would still be specified
as part of the style command (IconBeside/IconAbove), and after the
style flag rewrite would only require one bit to say to draw it above
the icon text or beside it.  Then you could have something like:

            Style "XTerm" Icon mini.xterm.xpm, IconBeside

or maybe:

                Style "XTerm" MiniIcon mini.xterm.xpm

to have one directive specify both (Icon <xpm> implies above, MiniIcon
<xpm> implies beside, last one specified wins).

Now, if the latter one were used, I *might* allow an extra pixmap
pointer to be stored in the window structure, so both a mini icon and
normal icon could be stored, and then *maybe* have a way in the
ButtonStyle directive to access that mini icon as one of the buttons.

I can't believe I just typed that...

But, it would allow for one per window xpm button without taking up
too much additional memory and fvwm wouldn't have to do any work to
create it.  Communicate it with the rest of the window info and
modules have access to it...

Jason> I was thinking that after you reach a certain level of
Jason> complexity (piles of window decoration parameters) it becomes
Jason> worthwhile to generalize things.
....

Perhaps, yes.  But, are piles of window decoration parameters
necessary?  That's what I was getting at.  I just want to be careful
about what's added.

Jason> Does anyone really make some windows look vastly different than
Jason> others?  I can see having different colors, but not different
Jason> border widths and shading.

If people want different colors, I can see people wanting different
widths and shadings too...

Jason> I meant that allowing pixmaps as title-bar buttons has got to
Jason> be easier than the vector-style method fvwm uses now.  Then
Jason> again, the vector method is nice because the buttons can be
Jason> scaled....

As of the current beta (2.0.42) title bar buttons can be pixmaps, just
not on a per window basis (global only).  I incorporatted Andrew's
patch for that.

BTW - I was thinking of an easier way to specify the vectors of the
normal buttons.  Something like:

  # Big square:
  ButtonStyle 2 Vectored HL(10,10,90,10) SH(90,10,90,90) SH(90,90,10,90) \
                         HL(10,90,10,10)

Where HL -> draw in Highlight color, SH -> draw in Shadow color, and
it draws in that color from x1,y1 to x2,y2 (percentage values, of
course).  Might need the number of lines specified in there too (right
after the Vectored keyword).

Of course, the old style would be available as well.

Chuck