Subject: removing 'Panel' feature from FvwmButtons?

From: Dominik Vogt <[email-masked]>
Date: Thu, 12 Aug 1999 14:34:48 +0200

I'd like to disable the 'panels' in FvwmButtons soon.
The implementation is very disruptive and makes writing
new features like coloursets very hard and complicated. I
think this can be done in a much simpler way:

 1) FvwmButtons tells fvwm to invoke a new instance of itself
    when a panel has to be opened like this:

      Module FvwmButtons FvwmPanelFoo

    as the action of a specific button. The panel would
    simply have its own config strings.

 2) An option for FvwmButtons is implemented that controls
    if the module vanishes after the first press or if it
    stays up when something is selected.

 3) We implement a command line geometry option for FvwmButtons
    and define some way to paste the desired position into the
    action string (much like the % arguments in functions).

 4) FvwmAnimate is enhanced to allow animations when windows
    map or unmap somehow.

This way we would have a much cleaner FvwmButtons again that
is smaller and easier to maintain.

Any ideas, comments or volunteers?

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-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: Brad Giaccio <[email-masked]>
Date: Thu, 12 Aug 1999 08:50:44 -0400

Hey I don't want to here you complaing, about colorsets, I had to get
most of the pager done, :). I think that sounds like a good way to go.
But maybe you should consider only execing the module once and using
ascheme where it just gets unmapped and then mapped when needed again.

On Thu, Aug 12, 1999 at 02:34:48PM +0200, Dominik Vogt wrote:

> I'd like to disable the 'panels' in FvwmButtons soon.  The
> implementation is very disruptive and makes writing new features like
> coloursets very hard and complicated. I think this can be done in a
> much simpler way:
>
>  1) FvwmButtons tells fvwm to invoke a new instance of itself when a
>  panel has to be opened like this:
>
>     as the action of a specific button. The panel would simply have
>     its own config strings.
>
>  2) An option for FvwmButtons is implemented that controls if the
>  module vanishes after the first press or if it stays up when
>  something is selected.
>
>  3) We implement a command line geometry option for FvwmButtons and
>  define some way to paste the desired position into the action string
>  (much like the % arguments in functions).
>
>  4) FvwmAnimate is enhanced to allow animations when windows map or
>  unmap somehow.
>
> This way we would have a much cleaner FvwmButtons again that is
> smaller and easier to maintain.
>

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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, 12 Aug 1999 09:00:05 -0400

> ascheme where it just gets unmapped and then mapped when needed again.

If anyone goes for the map/unmap solution, check out how FvwmForm
does it.  I wasn't crazy about the inconsistency  in the API
so I documented it as a feature that would probably change.

--
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: Thu, 12 Aug 1999 17:03:41 +0200

On Thu, Aug 12, 1999 at 08:50:44AM -0400, [email-masked] wrote:
> most of the pager done, :).

No, I was complaining about FvwmButtons :-)

> I think that sounds like a good way to go.
> a scheme where it just gets unmapped and then mapped when needed again.

That would be a possible enhancement, but you don't necessarily
need it. I don't know if you are familiar with FvwmButtons. The
implementation of the panels just creates a list of configuration
structures. As soon as you begin definig a panel it is very
difficult to access previous panels or the main panel. This makes
enhancing FvwmButtons extremely difficult, tiresome and risky.

If someone would help me with the map/unmap solution and/or
the FvwmAnimate enhancement I'd be grateful.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 13 Aug 1999 15:46:24 +0100

> think this can be done in a much simpler way:

I'm all for simplification as long as we can provide a method to achieve
panels that is no more difficult than the current one.

>     stays up when something is selected.

Someone already asked for it to map/unmap rather that start/exit.  I
think it would be best if that were possible as you could swallow things
in the panel and not have them killed/restarted all the time. In my past
life as a sys-admin I used to have a panel with xload's running on
different machines which was a very good way of spotting problems. 
Having to wait for ten xloads to start would be a pain

>  4) FvwmAnimate is enhanced to allow animations when windows

This would require a start position as well as a destination, it might
be possible to add this in conjuctions with having FvwmAnimate deal with
NoIcon windows.

How about if FvwmAnimate could keep a list of window-names, classes,
resources and window-ids together with a dissapear-to rectangle such
that M_DELETE messages and M_ICONIFY for NoIcon windows cause an
animation to that rectangle.  M_Add_window could make an animation from
a default rectangle.  I think this might answer the request for
Iconifying into a taskbar if the taskbar did a "Sendtomodule FvwmAnimate
dissapear_to $windowid x y width height" for every button.

The main FvwmButtons would set the button that controls the sub-panel an
the dissapear-to rectangle and send a toggle-unmap-state message to the
panel. The panel would map/unmap and FvwmAnimate would see the
M_ADD_WINDOW/M_DELETE_WINDOW and do a nice animation.

> Any ideas, comments or volunteers?

I used to do a slide up subpanel before FvwmButtons had panels (before
AnimatedMove as well) by having the main button execute a function like:

AddToFunc slideupdown I Next [panel] slide
+ I None [panel] make_panel

AddToFunc make_panel I FvwmButtons panel
+ I Wait panel
+ I slide_on

AddToFunc slide_on I Next [panel] Move <on screen coords>
+ I DestroyFunc slide
+ I AddToFunc slide I slide_off

AddToFunc slide_off I Next [panel] Move <off screen coords>
+ I DestroyFunc slide
+ I AddToFunc slide I slide_on

I can't rememeber if it was this simple or if I had to go through hoops
to get self modifying functions to work but it did work.  The only
things lacking were StackAbove and StackBelow functions to place the
panel just above the main after sliding up and just below before sliding
down.

Subpanels without the Panel mechanism are possible now so I vote to
remove the panel feature and we can work on how to make it easy
afterwards.

Cheers,
Tim.

PS is it open season on backwards compaitibility? If so can we remove
decors and expand the style structure to duplicate what decors provided?
--
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: Sat, 14 Aug 1999 01:10:23 +0200

> panels that is no more difficult than the current one.

It will be *easier* of course. Most people (including me) have trouble
setting up their own panels at the moment already, so it can't become
much worse.

> Having to wait for ten xloads to start would be a pain

I think it can be done in the same way as swallowing applications.
The only difference is that the application is not visible by
default but only after the button in pressed.

> >     action string (much like the % arguments in functions).

This is done.

> be possible to add this in conjuctions with having FvwmAnimate deal with

No, the destination is enough in this case. Sliding windows to open
them can be handles with only the destination geometry.

> M_ADD_WINDOW/M_DELETE_WINDOW and do a nice animation.

This should work too. It's a bit different than the current sliding
animations in FvwmButtons. Perhaps we can have both.

> decors and expand the style structure to duplicate what decors provided?

I didn't dare to suggest it :) All this stuff with Decors, ButtonStyles,
BorderStyles and TitleStyles is weird and needs a rewrite. I wouldn't
start with decors personally and instead begin with the other three.
Any opinions on this? I can't imagine we could keep backwards
compatibility with these commands if we rewrite them.

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]