On 27 Jul 01 at 11:56, fvwm-workers@fvwm.org wrote:
> - Code is written with 80 characters per line, a basic
> indentation width of 2.
> - Always compile the code with and without your ifdefs. Remove
> all warnings (compile with 'make CFLAGS="-Wall -Werror -g").
Okay. I usually set CFLAGS="-W -Wall" -- this gives more interesting
info.
> - Please keep in mind that that fvwm is controlled and configured
> by configuration commands, not by environment variables. It's
> not necessary to make features configurable via the
> environment. (I'll remove the corresponding code).
As to this point, one reason was an ability to pass these parameters to
modules (so that they will automatically be inherited via environment), and
another is that some other proggies can theoritically use XiSupp.c (think
about XMMS and various toolkits) or a similar thing, and they have no
standard means of communicating to FVWM.
Sure, modules interface can (and should?) be extended to accept
PrimaryScreen change, but this is mostly irrelevant -- primary screen is
usually taken into account only at startup.
> - Please try to use one of the formatting styles that is used in
> the fvwm code (indentation style). Try not to put commands on
> the same line as a condition.
BTW, I looked for some style guide inside fvwm sources, but didn't find
any. Your recommendations are definitely worth putting to some
fvwm_style_guide.txt.
> - RandR support will certainly be no part of 2.4.1. You should
> really try to split the patches you made on your disk into
> several patch files that can be applied individually.
Well, the RandR support can be at the same position as multibyte support -
it is present but switched off by default. When HAS_RANDR is undefined,
RandR will have no effect at all -- nothing will be queried in XiSupp.c, and
no RandR handlers will be called in events.c and FvwmPager.c.
I added RandR support as an additional step forward -- it enables to
understand which currently used concepts will become obsolete in some near
future, and what should be changed for more flexibility. That was the main
goal, not an ability to use resize feature of yet very rarely used KDrive.
;-)
> One question about the XiParseGeometry function: I don't
> understand why is does so many things. It really shouldn't do
> more than just parsing the geometry string like XParseGeometry
> does and use the same signature. I'll comment out all the extra
> stuff for now.
The answer is that modules do way too many calculations themselves
(negative handling, gravity selection, etc.). Much of them are duplicates,
and with submitted XiParseGeometry() modules become much simpler -- you add
one/two lines and remove sometimes several dozens (look at patches for
modules).
Well, maybe XiParseGeometry is not a very appropriate name, in fact what
this function does is very similar to XWMGeometry.
___________________________________________________________________
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13
--
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]
