Hi Dominik,
> > > Currently, the Active{Colorset,Title,Icon} are used. If none are
> > > specified then Colorset, Title & Icon are used. The effect you
> > > describe is achievable by setting PressColorset to the same colorset
> > > as your ActiveColorset (formerly HoverColorset). I'm undecided if
> > > this is the right behaviour ...
> >
> > I think this is the right behaviour - it's the main reason we have
> > PressColorset, PressIcon & PressTitle in the first place. It doesn't
> > make sense to override them with the Active* options.
> >
> > Things get complicated when no Press* options are specified, but the
> > current behaviour is still coherent when a button is waiting for a
> > window to popup (& the active button could be elsewhere).
>
> Okay.
>
> But with the latest patch, almost all the bugs I fixed a couple of
> days are back (which is no big surprise as most or all of the code
> I changed is gone).
>
> 1) After clicking on a button it is no longer hilighted.
This is what I was talking about (see above). Presumably you have
no PressColorset specified & are using an action like:
Action Exec "xmessage" exec xmessage hello
Maybe you'd like an option to override the Press* options with the
Active* options (what's the point of having Press* options then?).
I suppose an option to override Press* options with Active* options
if-&-only-if no Press* options are specified could be warranted ...
> 2) Press mouse button 1 on a button without releasing it. It now
> is drawn with PressColorset.
> Press button 2 without moving the mouse to cancel the action.
> ==> the button is drawn using the normal colorset while it
> should use the ActiveColorset.
Yep. A bug - will fix soon.
> 3) Press and hold a mouse button over a button. It gets
> hilighted as it should. Then move the pointer out of the
> button into another button.
> ==> It is still hilighted and sunken, but should be raised and
> not hilighted.
>
> 4) Same as (3), but move the pointer out of the FvwmButtons
> window.
3 & 4: The current behavior is as Mikhael requested. See earlier
posts. (Maybe I misinterpreted?)
> Would you please consider backing out your latest changes and redo
> them without removing the code I wrote?
With only one minor bug, hopefully I've convinced you this isn't
necessary. Of course, if you still feel that it is necessary I will comply.
In the interests of harmonious future collaboration I'd like to air
a couple of thoughts:
It's a bit frustrating having multiple people working on exactly the
same bit of code. One could argue that this is the nature of distributed
projects. However, I like to think that most of the time this can be
avoided. In this case, it was clear I was working on the FvwmButtons
module - if a similiar situation were to arise in the future, can I
suggest just requesting me to fix bugs &/or make implementation changes?
This would prevent me from effectively undoing your changes which must
be equally frustrating for you.
Upon reflection, maybe I caused this problem by not checking in my
bugfixes earlier. By my logic, there were no "showstoppers" (mostly
minor cosmetic bugs) in CVS, so I kept fixes in my own tree for a
couple of days so I could thoroughly test while I added a couple of
other features. Perhaps I should commit fixes as soon as they are
done? Don't know. All suggestions/discussion on the way I work on
FVWM most welcome.
Anyway, I hope this discussion isn't inappropriate. I'm hoping some
clear communication now will enable me to avoid causing futher problems
later on.
SCoTT. :)
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
