Subject: Events in Fvwm: Mouse-over type events on buttons?

From: Jay Kuri <[email-masked]>
Date: Mon, 15 Mar 1999 23:01:18 -0500 (EST)

How difficult would it be to trigger an event (such as EnterNotify) on the
title-bar buttons?

I took a look at the title-bar related stuff in events.c and everything
seems to be set up to pass all events to the frame.  Why is this, and is
it then possible to catch EnterNotify events on the buttons?

The reason I am asking is related to a message someone sent, mentioning
pop-up-type balloon help.  I got to thinking about this and thought that a
Balloon-popup type thing would be great to have.  Obviously it is the
perfect candidate for a module (it doesn't really belong in fvwm-core), a
FvwmBaloon module.  Unfortunately FVWM's structure now doesn't lend itself
to non-key, non-click events.  

I would like to see the event-capability and module-capability expanded.
I think that if we could add EnterNotify/LeaveNotify Events (at least on
TitleButtons) we would open up the door for some really cool
extension-type modules.  

Thoughts?

Jay

--
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: Tim Phipps <[email-masked]>
Date: Tue, 16 Mar 1999 09:22:52 +0000

> to non-key, non-click events.

While I was hacking at the order drawing code I had similar thoughts.  I
think the path of least bloat for fvwm is to extend it to pass on the
window IDs of the frame decorations, title bar and buttons in the
configure_window module message. A module could then ask for enter
notify events on those windows and pop up a suitable balloon message a
short time after the mouse stops moving in the button. What to put in
the message is tricky, just the function name isn't going to be much
help (I bind my_titlefunc to my title bars). It's probably best to just
have the balloon text in the module config.

I had thought about a ModuleDecorate style option that would tell fvwm
to not draw anything in the borders and let a module do all the drawing
but it will have to wait until after the GSFR.

> TitleButtons) we would open up the door for some really cool

I think this is achievable just by informing the module of the window
id's of the buttons and letting it select for enter/expose/click events.
The module would do all the visual stuff and fvwm would just do the
function calling.

NB I changed the resize handle windows to be InputOnly recently, I was
going to do the same to the title bar and buttons but chickened out
because it would probably end up breaking backward compatibility with
UseTitleStyle for the buttons and it would be very difficult to avoid
flickering the title bar and buttons if they didn't share the same
background as the border.

Being InputOnly means you have to draw in the frame and it may have been
a mistake but it made it easier to do the border drawing and it means
the DGradient borders are simpler to implement (left as an exercise for
the reader 8-)
> Thoughts?
I'd really like to have a bit more flexibility in the border layout and
a module may be the way to do it without bloating fvwm.  There's no
reason a module shouldn't be responsible for doing the graphics in the
window frame, with a few more fields in the FvwmWindow struct and a
couple of commands to set border widths, a module could set the border
size and move the title bar and buttons around in the frame. You could
have the buttons down the left hand side and the title bar on the bottom
if you want (with a stock ticker running along the top of the focussed
window, and your current CD track title down the right!)

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Tue, 16 Mar 1999 16:22:58 +0100

> window, and your current CD track title down the right!)

The idea of enabling modules to draw the decorations sounds neat,
but the decoration you describe sounds too "enlighted" :-)

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Jay Kuri <[email-masked]>
Date: Wed, 17 Mar 1999 18:37:34 -0500 (EST)

[ ... ]
> short time after the mouse stops moving in the button. 

	I think this would work fine... Does anyone have objections to
implementing something like this?  (I would be willing to work on it)
Maybe making it an extended-info fvwm->module message-type?  

> What to put in

	I was thinking about this in terms of theme-configs... the ability
to assign short-help-messages to buttons.  The theme module could
configure the pop-up help module.

> The module would do all the visual stuff and fvwm would just do the
	I like this idea alot.  

> a module may be the way to do it without bloating fvwm.  There's no
[ snip ]
> window, and your current CD track title down the right!)

	heh. This does sound a little "enlightened"  but the overall idea
is great.  The ability for a module to be responsible for decorating
windows I think would be great.  It would certainly make it apealing for
things like the gnome project and whatnot, as it would allow fvwm to look
however someone wanted it to look, and would keep fvwm's bloat down.  That
would truly make it a 'Flexible Virtual Window Manager' (Virtual in a new
way)  

The other thing that we could then do is save the real fancy style-ish
stuff for a module... so that we aren't bloating fvwm-core
with gradient-code and dithering and you-name-it-for-next-week features.

Leave the basics in... but let the module(s) handle the next bit.  I'm not
convinced it would require much by-way of extension of the current fvwm
code.  We would want to allow the module to specify frame dimensions
before fvwm starts building it.  Then the module could build into the
frame and call fvwm functions and whatnot based on the module's config
for user actions.

What are everyone's thoughts about adding these to the list of FVWM goals?

	Provide ability for modules to be responsible for window
decorations... (and others? menus?)

	Provide ability to get more info on windows (frame, button window
id's, etc) for functionality extension in modules.

Jay

---

From: [email-masked] (Paul D. Smith)
Date: 17 Mar 1999 19:00:37 -0500

Whenever I hear about modules handling decoration, I wonder if it
wouldn't be interesting to consider changing modules from separate
processes communicating by pipes into dynamically loaded object
modules.

In this way you could get much closer and faster integration between
modules and FVWM, while still leaving FVWM lean (it would only load the
modules you were interested in).

These days, with so many apps doing "plug-in" like functionality, more
and more OS's are providing things like dlopen() and making them work
correctly.

Well, obviously longer term but I wonder what people think.

One advantage to the current method is that it's harder for a broken
module to screw up the WM proper--but, not impossible as we've seen even
now.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Jay Kuri <[email-masked]>
Date: Wed, 17 Mar 1999 21:52:34 -0500 (EST)

I'm not too familiar with dlopen() and module-programming in this way..
For my own education, what would be the advantages to using a module like
this over just handling the window-decorations directly in a module and
communicating over the module-interface?

Would this mean that we would have... say... a 'decor' DLM, which the 
user could replace with some sort of custom module?  Would the 'default'
decor types have to be in a module as well? 

Jay

---

From: [email-masked] (Paul D. Smith)
Date: 18 Mar 1999 10:02:25 -0500

%% Jay Kuri <[email-masked]> writes:

  jk> I'm not too familiar with dlopen() and module-programming in this
  jk> way..  For my own education, what would be the advantages to using
  jk> a module like this over just handling the window-decorations
  jk> directly in a module and communicating over the module-interface?

Essentially, the advantage is you're running in the same process and so
can share memory, datastructures, etc.  In other words, we wouldn't need
to pass all kinds of data over pipes between processes, they could be
accessed directly.

  jk> Would this mean that we would have... say... a 'decor' DLM, which
  jk> the user could replace with some sort of custom module?  Would the
  jk> 'default' decor types have to be in a module as well?

It wouldn't have to be, but why not?  Then it could be swapped out if
the user didn't want it.

---

From: Dan Espen <[email-masked]>
Date: Thu, 18 Mar 1999 10:13:12 -0500

> It wouldn't have to be, but why not?  Then it could be swapped out if

I think the dlopen path  is worth looking  into, but we haven't really
fully   exploited the current module  approach.   In my mental list of
pending things to do  is  enhance "send_configinfo"  so that  you  can
indicate the particular module you want config  info for.  This should
cut down the pipe traffic for modules considerably.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
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: Matthias Clasen <[email-masked]>
Date: Thu, 18 Mar 1999 16:17:06 +0100

> to pass all kinds of data over pipes between processes, they could be

I also had this thought that some kind of shared mem access to the 
window list would be much nicer than maintaining the same list in 
every other module.

Matthias