On Sat, Jul 10, 2004 at 07:20:10PM +1000, Scott Smedley wrote: > > > Ditto. FvwmButtons is quite complex. Consequently, I'm not comfortable > > > commiting this patch until it's had wider testing. Maybe you can convince > > > some fellow FVWMers to try it out? :) > > > > You'd encourage at least one more FVWMer if you'd just commit the > > patch. Backing out patches is easy while having to apply patches > > and taking care not to accidentally commit them is a pain :-) > > Ok, committed.
There was a crash when the pointer enters unused button space, i.e. slots that are not allocated to any button. I have fixed this, but there may be similar bugs in other parts of FvwmButtons. Other issues with HoverColorset: 1 When you click a button, it is drawn in the original colours as long as the mouse button is held. Shouldn't it also use the HoverColorset? This is because the ButtonPress handler does not take the current HoverButton into account. 2 Move the mouse on any button with an action bound to it. The button is hilighted. Now press and release a mouse button ==> The button is no longer hilighted. This is because the ButtonRelease handler does not take the current HoverButton into account. 3 Press a mouse button on a button, drag the pointer to another button, then release the mouse button without moving the mouse ==> The button under the pointer is not hilighted. As soon as the mouse moves it switches to the HoverColorset again. 4 When the pointer is on a container or a swallowed application, the border of that container is hilighted. I think only buttons that actually have an action bound to them should be hilighted (maybe this should be configurable). 5 I'm not sure "Hover" is a good name. I associate all kinds of things with "hovering", but definitely not the current behaviour. In the menu code we use "Active" for that purpose. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED]
pgpA1PYjsxVSX.pgp
Description: PGP signature
