Subject: A few things

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Thu, 29 Mar 2001 13:58:03 +0700

Hi!

    While xineramifying Fvwm, I've encountered a few side small problems:

1. FvwmPager accepts "-transient", while FvwmWinList -- "Transient".
   Shouldn't they use the same syntax?

2. FvwmTaskBar.1 refers to "stfrtime" instead of "strftime" (just a typo).

3. FvwmTaskBar.c uses a value of "2" for its height in the AutoHide mode,
   which interferes with EdgeThickness ("2" is default).  Maybe "3" or "4"
   will be better?  (BTW, there too many "2"s in the text -- maybe
   #define/enum HIDDEN_HEIGHT nnn could be cleaner.)  And even more --
   wouldn't it be better for *FvwmTaskBarAutoHide to accept an optional
   parameter "hidden size", since on 1600x1200 displays 2 or 3 pixels is too
   small.

    BTW, FvwmTaskBar is a nightmare -- the positioning logic is spread
between many functions, along with "magic numbers" like "2" and "magic
formulae" like "ScreenHeight-win_border...".  (In fact, there are much more
problems with FvwmTaskBar, but I hope they'll disappear once I finish
concentrating all these magic in a single ConfigureGeometry().)

       ___________________________________________________________________
       Dmitry Yu. Bolkhovityanov  |  Novosibirsk, RUSSIA
       phone (383-2)-39-49-56     |  The Budker Institute of Nuclear Physics
                                  |  Lab. 5-13
--
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: Thu, 29 Mar 2001 11:31:06 +0200

>    Shouldn't they use the same syntax?

Well, probably.  There are so many strange and inconsistent things
in the various syntax patterns that it seems futile to start with
fixing module syntax.  I'd like to clean up all the syntax for
3.0.

> 2. FvwmTaskBar.1 refers to "stfrtime" instead of "strftime" (just a typo).

Corrected.

>    parameter "hidden size", since on 1600x1200 displays 2 or 3 pixels is too

To be honest I'd rather try to remove all icon management modules
except FvwmIconMan rather than fixing FvwmTaskBar.  It's written
very uncleanly and has not been maintained properly for years.
Personally I avoid value constants completely.

> concentrating all these magic in a single ConfigureGeometry().)

FvwmTaskBar *is* a nightmare.  

I'll record your comments as enhancement requests.  I won't open
that can of worms now, right before the 2.4 release.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Thu, 29 Mar 2001 13:24:33 +0200

Le Jeudi 29 Mars 2001 11:31, vous avez écrit :
> >    which interferes with EdgeThickness ("2" is default).  Maybe "3" or
> > "4" will be better?  (BTW, there too many "2"s in the text -- maybe

AutoHide and Vertical Scrolling are incompatible that's all :o)
Of course, *FvwmTaskBarAutoHide hidden_size will be a
good option. Note that you can play with the border width, 
what about: Style "FvwmTaskBar" BorderWidth 10 (of course
do not fix AutoHide + Vertical Scroll).
There is also the possibility to do a manual hide by shading
the taskbar with a doubleclick on its border (the best solution
IMHO, AutoHide cause to many problems). 

> except FvwmIconMan rather than fixing FvwmTaskBar.  

And FvwmIconMan will become very very complex, because every
body will want this feature and this look (where is my "TaskBar" look?
why I've to spend 3 days to configure IconMan as WinList is so easy
to configure? ...etc).  Any way, at the present time I've no opinion
on this subject.

> It's written
> > formulae" like "ScreenHeight-win_border...".  (In fact, there are much
> > more problems with FvwmTaskBar, but I hope they'll disappear once I
> > finish concentrating all these magic in a single ConfigureGeometry().)
>

Yes, I try to maintain the TaskBar a bit. I use it every day and I do no
see any problem if you use it in a normal way (no AutoHide with Vertical 
Scrolling, do not change the border width together with shading/move/resize
it  (with AutoHide), and there is also this Autostick "feature" and timeout
balloon etc..). Unfortunately (or fortunately) I never take the responsibility
to do a complete rewriting, but I tried to fix it "bit by bit".

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 29 Mar 2001 15:38:36 +0200

> to configure? ...etc).  Any way, at the present time I've no opinion

I think you underestimate what FvwmIconMan can already do.  At
present it can mimic the basic functionality of FvwmTaskBar almost
perfectly.  As far as I know it only lacks an autohide feature and
the tray with the clock and mail items.  It can also behave like
FvwmWinList or the WindowList command, except perhaps that it
lacks some of the sorting options.

On the other hand, FvwmIconMan is not written very cleanly either
and is hard to debug.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 29 Mar 2001 20:20:30 -0600

> lacks some of the sorting options.

I would not underestimate the Olivier's knowledge of FvwmIconMan,
FvwmWinList and FvwmTaskBar. :) He personaly has no problems to fully
configure any of these (see olicha theme), but is concerned about users.

Currently FvwmTaskBar is more like a ready-to-go FvwmButtons with the
start button + FvwmIconMan + smart mail box + clock. I can agree with
Olivier that trying to incorporate all unique features of FvwmTaskBar into
FvwmIconMan may cause a spaghetti. Removing FvwmWinList is easier.

I don't think that adding a FvwmButtons-like code to FvwmIconMan is a good
idea. So I see only 2 solutions, either to continue with FvwmTaskBar
module or replace it with a FvwmButtons sample containing among others
FvwmIconMan. The problem with the second solution is as Olivier mentioned,
a lack of the current easy configuration in one place.

I also think that when FvwmIconMan and FvwmWinList will be merged the
resulting module for managing a list of windows is better to be called
FvwmWinList, not FvwmIconMan.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Mar 2001 11:26:52 +0200

> configure any of these (see olicha theme), but is concerned about users.

Of course.  The current plans for 3.0 would already break a lot
of syntaxes and make it very disruptive fr the users, but that is
no reason not to try to make the process easy for the users.
Perhaps it could be done as a special mode of operation a la
FvwmRearrange/FvwmTile/FvwmCascade.

> FvwmIconMan may cause a spaghetti. Removing FvwmWinList is easier.

I think we need to thigs: one module that manages icons (called
FvwmTheOnlyTrueIconManager ;-) ) and one module that provides gui
or button functionality (FvwmGUI?).  CUrrently, if we had to chose
from existing modules, the best choices are FvwmButtons and
FvwmIconMan.  It should be possible to implement everything else
bu using these two.  Doing so would require a major effort.

> a lack of the current easy configuration in one place.

Yes of course.  I didn't say removig one of the core modules would
be easy, did I?  BUt at the moment I *believe* that fvwm needs a
major rework of syntax anyway.  At least these are my (vague)
plans for 2.3:

 - Integrate FvwmTheme into fvwm.
 - Possibly throw away some of the modules.
 - Throw away TitleStyle/ButtonStyle/BorderStyle/Decors and
   replace them by styles.
 - Vastly improve flexibility of the Style command.
 - Rewrite large parts of the syntax in a consistent way.

> FvwmWinList, not FvwmIconMan.

Whatever.  I don't really care about the name.

Bye

Dominik ^_^  ^_^