Subject: Taskbar launchers & different mouse buttons

From: Suzanne Skinner <[email-masked]>
Date: Sat, 5 Oct 2002 02:07:48 -0400

Greets,

I've developed a patch which enhances Ben Mathews' excellent titlebar-launcher feature.
It allows one to specify different actions when different mouse buttons are
clicked on a launcher. It uses the same sort of syntax for this as
FvwmButtons, like so:

     *FvwmTaskBar: Button Icon terminal.png, Action (Mouse 1) Exec xterm, \
                                             Action (Mouse 3) Popup TermMenu

"Action Exec xterm" still works and defines a general action separate from the
others.

One application for this is the desktop system I'm developing for Fvwm, which
lets you dynamically configure elements such as the taskbar. So a user might
left-click on a launcher to execute it, or right-click to popup a control menu
for that launcher with choices like "remove from taskbar".

As a sort of zero-cost side effect, the Start Menu can also take different
actions for different mouse clicks with this patch:

     *FvwmTaskBar: StartMenu (Mouse 1) Mouse1Menu
     *FvwmTaskBar: StartMenu (Mouse 3) Mouse3Menu

If/when I receive write access to CVS (I'm waiting for cries of protest before
submitting the request to Jason :-), I can commit this myself, but of course
I'd like to okay it with everyone first.

Suzanne

-- 
[email-masked] - http://www.igs.net/~tril/
--
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, 5 Oct 2002 13:20:36 +0000

I wanted to write this before FvwTaskBar patch was applied, but realized
that 1) many use FvwmTaskBar, 2) I myself have no time to implement what
I suggest fully. Still maybe others agree with me.

Having 2 modules implementing the same is twice (if no more) work for
maintainance. FvwmButtons and FvwmIconMan already have all features that
users want to see in FvwmTaskBar. And vice versa FvwmTaskBar currently
has several features that FvwmIconMan users want to see.

Generally, every new or old feature should be duplicated.

I have several thoughs about a smooth transition from FvwmTaskBar to
FvwmButtons with swallowed FvwmIconMan. I think that having only one
module for layout (currently FvwmButtons, but the name may be changed
to FvwmPanel) is what we need and having only one module managing window
list (currently FvwmIconMan, but the better name would be FvwmWinList)
is what we need.

The idea may be this. We stop adding any features to other modules and
only extend FvwmButtons and FvwmIconMan. We then replace FvwmTaskBar with
a module that only converts its legacy configuration to FvwmButtons and
FvwmIconMan configurations (using aliases like FvwmButtons-FvwmTaskBar
and FvwmIconMan-FvwmTaskBar) and starts these modules. In the future we
encourage users to use only these 2 modules for creating their panels.

Suzanne, Ben, Olivier and other FvmwTaskBar lovers, is there a chance you
agree with such arrangement? Would not having one powerful FvwmPanel and
one or more "applets" to be optionally swallowed be a better solution?

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 05 Oct 2002 09:29:40 -0400

> Greets,
...
> I'd like to okay it with everyone first.

Please, go ahead and send the request, you've submitted more
than enough patches to qualify.

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

---

From: Bob Woodside <[email-masked]>
Date: Sat, 5 Oct 2002 10:49:31 -0400

On Sat, 5 Oct 2002 02:07:48 -0400
Suzanne Skinner <[email-masked]> wrote:

> If/when I receive write access to CVS (I'm waiting for cries of
> protest before submitting the request to Jason :-)....

	No cries of protest, just applause. I think the vote is unanimous
acclamation. Please go ahead and submit the request.

Cheers,
Bob

---

From: Ben Mathews <[email-masked]>
Date: Sat, 05 Oct 2002 12:42:32 -0400

> one or more "applets" to be optionally swallowed be a better solution?

I kind of think that calling a taskbar anything other than a taskbar 
might be confusing to anybody not familiar with fvwm, but you also have 
a very good point about having less code to maintain.

Could you post your fvwm2rc file that shows how you got the neat XP 
taskbar with FvwmButtons shown on the screenshot?  It looks pretty cool.

Ben Mathews

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 5 Oct 2002 18:53:37 +0200

> acclamation. Please go ahead and submit the request.

Yes!
Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 5 Oct 2002 17:22:55 +0000

On 05 Oct 2002 12:42:32 -0400, Ben Mathews wrote:
> might be confusing to anybody not familiar with fvwm,

I don't think so, does GNOME or KDE have a separate concept of task bar?
They have a concept of a configurable panel, something that we all try to
achieve.

> but you also have a very good point about having less code to maintain.

Actually there is one more solution. The goal is to have only one code and
one syntax for one complete feature. But this feature may be embedded in
several modules. I.e. create a library that is used in 2 or more modules.

But I think that whoever writes such library will come to a conclusion
that it is more clean to have modular setup, like FvwmPanel swallows
FvwmWinList (I use here the ideal names) than to try to embed such big
features like fully featured window list a-la FvwmIconMan or fully
featured button layout a-la FvwmButtons.

This does not mean other features like time-outed tips/balloons can't be
moved to the library for use in all C modules.

> taskbar with FvwmButtons shown on the screenshot?  It looks pretty cool.

Well, you can't see what it does (it is dynamical) without running it.
To get the configuration, get the fvwm-themes cvs (or browse it online).
You want the files in themes/redmondxp/modules/ directory. Some knowledge
of how the modules component works in fvwm-themes may help too.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 6 Oct 2002 00:56:50 +0200

> of how the modules component works in fvwm-themes may help too.

Yay!  Let's dump yet another module! 8-)  FvwmTaskbar is way too
difficult to maintain already.  A modular setup sounds fine.  The
FvwmTile/FvwmCascade -> FvwmRearrange way may work too:  Replace
FvwmTaskBar with a symbolic link to FvwmButtons and add a
"--taskbar" option too (note that I'd like to move to GNU style
long option names in the future).  When FvwmButtons is started in
"TaskBar" mode it reads all "*FvwmTaskBar..." config lines and
translates them to the proper FvwmButtons config language.  The
translation may be done by calling a perl script.  This is what
has to be done:

 * Add the FvwmButtons taskbar mode code and provide default
   options to emulate a plain FvwmTaskBar by default.
 * Write a translation script.  This is the tedious part.
 * Add the features that are missing in FvwmButtons/FvwmIconMan.

In the same way, it should be possible to emulate FvwmWinList with
FvwmIconMan (FvwmWinList shares a lot of the FvwmTaskBar code).

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: Suzanne Skinner <[email-masked]>
Date: Sat, 5 Oct 2002 21:45:34 -0400

> one or more "applets" to be optionally swallowed be a better solution?

I'd have no problem with this, as long as it really is (or will be) possible
to exactly imitate the "taskbar" look with FvwmButtons + FvwmIconMan. I've
been using FvwmTaskBar to give my husband a reassuring Windozy feel when he
logs into Linux :-)

Still, is it okay if I commit the FvwmTaskBar improvement that I've already
developed?

Suzanne

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 6 Oct 2002 02:51:36 +0000

On 05 Oct 2002 21:45:34 -0400, Suzanne Skinner wrote:
> > Suzanne, Ben, Olivier and other FvmwTaskBar lovers, is there a chance
> > you agree with such arrangement? Would not having one powerful
> > FvwmPanel and one or more "applets" to be optionally swallowed be a
> > better solution?
> 
> I'd have no problem with this, as long as it really is (or will be)
> possible to exactly imitate the "taskbar" look with FvwmButtons +
> FvwmIconMan. I've been using FvwmTaskBar to give my husband a reassuring
> Windozy feel when he logs into Linux :-)
> 
> Still, is it okay if I commit the FvwmTaskBar improvement that I've
> already developed?

Well, relatively to what is already duplicated, duplicating one Action
parameter is not very much. I have no objections.

But, it would be nice if we would think more about extending FvwmButtons
and FvwmIconsMan in the future, i.e. how to make them FvwmTaskBar capable
if not yet.

Is anyone interesting in adding the following features to FvwmIconMan:

  * a configurable maximal item width (like *FvwmTaskBar: ButtonWidth)
  * tooltips (like *FvwmTaskBar: ShowTips)
  * a configurable spacing between items
  * a configurable fixed item height (we have no analogue yet)

The last feature would enable automatical switching from one row to two
and more rows when FvwmPanel (i.e. FvwmButtons) is resized.

The next is moving of any-window-autohiding to fvwm or a module.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 6 Oct 2002 09:04:35 +0200

>   * tooltips (like *FvwmTaskBar: ShowTips)

Should be in a lib (some users ask this for FvwmButtons).

>   * a configurable fixed item height (we have no analogue yet)

One very interesting feature of the TaskBar is that its width is
exactly the screen width whatever the border width (this is even
dynamical). So for me a must is:
 
 * Do so that FvwmButtons understand % geometries as width%pw x height%ph:
   force the geometry of the FvwmButtons window (border width taken in
   account) to be ScreenWidth * pw/100 x ScreenHeight * ph/100. This
   should be maintained during FvwmButtons life.

An other minor feature of the taskbar is the asymmetric look of the
relief of the buttons. Users may complaint if this disappear.
Also there is the "..." feature and AutoStick. But I do not like
these two :o)

Also, it seems to me that it will be difficult to simulate FvwmTaskBar
resizing with a FvwmButtons: StartButton and GoodiesButton have fixed
size as the "WinList" use the full height. Note that I always resize
my TaskBar during a session. 

About Goodies: Mikhael is FvwmPerl can be used to write a "Proc" modules:
A module which will send (configurable) string and Icon with a configurable
period whenever
- The time change
- The used disk swap space / memory change.
- battery state change.
- Cpu info change.
- mailbox change.
- etc ...

Maybe there is a "proc" Perl module?

> The next is moving of any-window-autohiding to fvwm or a module.

Ah yes this is an important feature. It is broken but it works
surprisingly well :o)

My conclusion. Yes it is a bit stupid to maintain 3 modules for
"window list". I vote for the replacement of the FvwmWinList by
a symlink and a warped config (one "sort" issue here).
For the TaskBar, in the view of the enormous work needed (I do not
want to do it now), I think that we should put the FvwmTaskBar
removal in the 2.8 or 3.0 todo list.

Moreover, I think that FvwmTaskBar is easy to maintain. I am agree
that the code is not terrible. But IconMan code is really terrible!

So one thing which should be done too is to make a big clean up
of FvwmIconMan code.

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 6 Oct 2002 13:18:01 +0000

>    should be maintained during FvwmButtons life.

Probably extend FScreenParseGeometry to support 100%x5% syntax.

> relief of the buttons. Users may complaint if this disappear.

FvwmIconMan already supports 5 types of relief, adding more would be nice.
How about oval 3d borders and small spacing between buttons. :)

> Also there is the "..." feature and AutoStick. But I do not like

Actually AutoStick may be interesting as a general window feature, but it
is really not a showstopper.

> my TaskBar during a session. 

Yes, the current table-only center-expand-and-fill layout management of
FvwmButtons does not permits this, but it is not very bad as it works now.

> Maybe there is a "proc" Perl module?

Even if such package exists, I don't want users to install anything from
CPAN (except for Gtk-Perl, because this is too nice GUI to miss it).

I am ready to write FvwmMonitor (or whatever this is to be named) once I
figure out the monitoring code for memory/disk/battery/cpu.

> removal in the 2.8 or 3.0 todo list.

If we speak about names and symlinks, probably the new super-windowlist
module should have a new name. I may think about:

  FvwmWinList    (not really a new name, but it is the best for me)
  FvwmWindowList
  FvwmTaskList
  FvwmAppList

I don't like very much the last two, FvwmWindowList is ok.
So maybe as a temporary solution, copy FvwmIconMan to FvwmWindowList
and start to clean up FvwmWindowList? Or replace FvwmWinList?

> So one thing which should be done too is to make a big clean up

Yes, it is terrible. I think the multi-manager support may be removed.
I don't see a good reason to have it. Just run 2 FvwmIconMan's.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 7 Oct 2002 19:05:52 +0200

On Sun, Oct 06, 2002 at 09:04:35AM +0200, Olivier Chapuis wrote:
[snip]
>    should be maintained during FvwmButtons life.

I don't see how this helps to adapt to the screen width.  There is
still the problem that FvwmButtons can't easily find out its
border size.

Speaking of resizing FvwmTaskBar:  The

  *FvwmTaskBar: Colorset ...

background is not updated when the task bar is resized.  Instead,
the background is tiled.  Try

  *FvwmThemeColorset 6 vgradient 128 red green
  *FvwmTaskBarColorset     6

Perhaps someone could fix this.

> relief of the buttons.

Asymmetric look?  Never noticed that.  But anyway, the Draw3dRect
should be replaced with RelieveRectangle that is used everywhere
else.

> Users may complaint if this disappear.

Bah, users ;-)  Honestly, if someone can't live with a few pixels
drawn in a different colour, we may be better off to recommend not
to upgrade fvwm in the next ten years.

> Also there is the "..." feature and AutoStick. But I do not like

Shudder.  Maybe the most flawed "feature" in fvwm and its modules.

> my TaskBar during a session. 

Yup, this will be difficult.  The FvwmButtons layout is strictly
statical and can't easily be enhanced to add or remove cells on
the fly.  At startup, FvwmButtons creates a grid of button
pointers.  In the most simple case one grid cell is exactly the
size of a button, but for more advanced layouts the grid has more
cells.  The button placement algorithm may or may not add or
delete grid rows and columns, depending on the options.  Once all
buttons are placed in the grid ("shuffled"), the grid size becomes
static.  When FvwmButtons is resized, the size of the button bar
is divided evenly among the individual cells.  New cells are never
added anymore.

To find the button belonging to the pointer position, FvwmButtons
divides the offset from the top left corner by the cell size,
yielding a cell row and column.  Then it looks up the button
pointer in the grid cell.  This obviously depends on all the grid
cells being the same size.  (There is some more logic dealing with
button bar sizes that are not multiples of the grid size).

[snip]

> Maybe there is a "proc" Perl module?

All that needs to be done is to issue fvwm commands from a shell
script.  Pretty trivial.

[snip]

> Ah yes this is an important feature. It is broken but it works

Cough, cough!  I guess you never tried that with a non-sticky
taskbar ;-)  And there was a ConfigureNotify race condition for
years.  It's still in 2.4.x.

> that the code is not terrible. But IconMan code is really terrible!

I won't tell what I think about the code in various modules, but
keep in mind that the original authors of the modules may still
read this ;-)

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 7 Oct 2002 19:01:51 +0000

> still the problem that FvwmButtons can't easily find out its

I think Olivier suggested to solve it just like FvwmTaskBar does it.
By listening to M_ADD_WINDOW/M_CONFIGURE_WINDOW.

[snip]

> should be replaced with RelieveRectangle that is used everywhere

I think we need more than one (configurable) ways to create the 3d look.

> the fly.

I need such feature badly. How you would do the following. Dynamically add
or remove buttons in the given container. I am speaking not about syntax,
the syntax is pretty clear to me. To remove button from container:

  SendToModule FvwmButtons RemoveButton <buttonid>

To add new button to container:

  SendToModule FvwmButtons AddButton <containerid> <index> <newbuttonid>
  SendToModule FvwmButtons ChangeButton <newbuttonid> Title t, Icon i

Or may be create a button without the parent and then add it:

  SendToModule FvwmButtons CreateButton <newbuttonid> Title t, Icon i
  SendToModule FvwmButtons AddButton <containerid> <index> <newbuttonid>

The grid should be recalculated after such add/remove, I guess.
I didn't have a chance yet to see how to implement this.
Maybe you can help here and add this add/remove feature, please? :)

> All that needs to be done is to issue fvwm commands from a shell

We speak about the official FvwmTaskBar replacement here, right?

Maybe I don't understand you, but how is such shell script better than an
fvwm module written in perl (that is script too). In your solution:

  1) run shell/perl script (how, from cron, fork?) to send commands
  2) run FvwmCommandS module
  3) use external FvwmCommand in the script to send commands

In the solution that we with Olivier speak about:

  1) run persistent FvwmMonitor instance that periodically sends commands

Such FvwmMonitor gets parameters module-alias (to have several instances),
monitoring-type (battery/cpu/mailbox/time), time-interval (20 sec) and
other parameters that affect which command (title changed/icon changed) is
send and when. I bet, the "pretty trivial" script you speak about is
harder to implement than such module. Perl library helps a lot here.
Additionally, you may send dynamical commands to such module.

> keep in mind that the original authors of the modules may still

Woops! :-)

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Oct 2002 22:18:11 +0200

> By listening to M_ADD_WINDOW/M_CONFIGURE_WINDOW.

Yes.  But then we need to say "keep the given window size at all
cost".  We don't need a "percentage of screen size" geometry.

[snip]

> Maybe you can help here and add this add/remove feature, please? :)

Of course I can help here and there.  But implementing this
entails a full rewrite of the FvwmBUttons design.

> fvwm module written in perl (that is script too).

I just wanted to say:  regardless of wether FvwmPerl implements
this, we can already have the same without it.

[snip]

Bye

Dominik ^_^  ^_^