On Sat, 11 Sep 2010 at 23:05:26 -0400, Brad Jorsch wrote:
> On Sat, Sep 11, 2010 at 11:37:52AM +0200, Carlos R. Mafra wrote:
> > On Sat, 11 Sep 2010 at 12:02:14 +0400, Alexey I. Froloff wrote:
> > > Yet again, no, but one can always use $EDITOR. I agree, this is
> > > ugly, undocumented and stuff.
> >
> > Yeah, ok, but I think you will also agree this is not realistic.
> >
> > I doubt many users have the git sources and compile it themselves.
> >
> [...]
> >
> > I bet that to anyone wanting to modify the source to
> > disable the clip title would simply comment the line
> > which prints the title, instead of changing "YES" to
> > "NO" in another far away place in the source.
>
> I think "one can always use $EDITOR" was referring to editing
> ~/GNUstep/Defaults/WindowMaker, not to editing the source and
> recompiling. I haven't *tried* the patch, but isn't
> > > > + {"ShowClipTitle", "YES", NULL,
> > > > + &wPreferences.show_clip_title, getBool, NULL, NULL,
> > > > NULL},
> in the code that parses the config file?
That would make more sense.
But if that's the case, then it's also a first-class example that
the commit message was sub-optimal.
It should have mentioned how one should be supposed to use the
code. When people have to read the code to guess what should be
made to have the feature, that's bad for several reasons.
The same thing for the other patches which assume one will pass
a -D flag to CFLAGS to have the thing, or also use an $EDITOR to
define the shortcut etc. I do not want to complain about Alexey's
port, he has done a lot already. But these things must also be
considered if we want a high-quality repo/wmaker.
If I simply push the patches without making noise, who will
guess those things after doing a 'git pull' two years from now?
All those things will be simply lost in the code (I wonder
how many other things like these already exist).
It would be nice if someone feels motivated enough to contribute
documentation about these knobs. But in the meantime, I don't
want to add more hidden things without having a good way to
present them to users (including me).
--
To unsubscribe, send mail to [email protected].
