On Fri, Jul 16, 2004 at 12:14:38AM +1000, Scott Smedley wrote:
> 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
No, I'm not. When I click on any button, it ends up using the
standard colour set until the mous is moved. That has nothing to
do with the PressedColorset.
> 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 ...
> > 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
It wasn't clear to me.
> - if a similiar situation were to arise in the future, can I
> suggest just requesting me to fix bugs &/or make implementation changes?
Usually I don't bother, but in this case describing all the many
bugs in the old and new code I found would have taken more time
than just fixing them.
And by the way, this is the first time I can rember that a
conflicting check in caused a real problem - in the seven years
that I'm using CVS.
> This would prevent me from effectively undoing your changes which must
> be equally frustrating for you.
Well, my frustration came from the fact that I spent quite some
thought to get event handling straight, and all that code went
down the drain. But assuming we leave the button hilighting with
mouse button held as it is, all that complex code is no longer
necessary.
> 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?
I try to never keep uncommitted patches on my disk at the end of
the day because I tend to forget what I already committed and end
up describing the same change twice (or not at all) in the commit
messages.
If it's necessary to keep changes for a longer period of time, I
just ask on the list to keep the code alone for the time being.
> Don't know. All suggestions/discussion on the way I work on
> FVWM most welcome.
I usually care only about code readability and ease of
maintenance. My preferences are all written down in
docs/CONVENTIONS, but we never discussed any of these
suggestions.
Currently, I'm particularly unhappy with the level of nesting we
have in some code. In some files, it's impossible to keep lines
shorter than 80 characters. I hope that future code will nest no
deeper than 4 levels of indentation.
Another problem that is going to become worse in the future is
code that is correct by the C99 standard but not by C89
(specifically C++ style comments with // and declarations in the
body of code blocks, e.g. { int i; i=1; intj; }). Is there an
option to tell gcc to adhere to the C89 standard?
> 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.
You're not causing trouble, you're doing very valuable work. This
is what keeps fvwm alive.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
pgpFB0uxUN9zv.pgp
Description: PGP signature
