On 28 Jul 01 at 13:07, [EMAIL PROTECTED] wrote:
> > > - 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.
>
> Ah, okay. The solution to both problems is the module interface.
> Some settings like "Colorset" are communicated to the modules over
> the module pipe. The state of Xinerama{En,Dis}abled can be easily
> communicated too. In fact I have already done this. Take a look
> at the code in virtual.c:
>
> void CMD_XineramaDisable(F_CMD_ARGS)
> {
> XineramaSupportDisable();
> BroadcastConfigInfoString("XineramaDisable");
> }
>
> Any module listening for M_CONFIG_INFO packets will receive the
> string "XineramaDisable" when the function is called an can react
> properly. I think I still forgot to send this string when the
> module is initially started, so the module's Xinerama state may
> not match fvwm's state at first. I will take care of this.
>
> Any program that wants to communicate to fvwm tightly should be
> written as an fvwm module. Another way would be to communicate
> via FvwmCommand, but that is inefficient and littl internal
> information about fvwm's state it communicated this way.
>
> > 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.
The problem of other programs remain -- they should *not* communicate to
fvwm, they should work with *any* WM. In fact, the problem here is lack
of X.org specification. IMHO the natural way will be to use a root window
property -- like _XINERAMA_PRIMARY_SCREEN. In that case any program could
request notification of property's change. This isn't urgent, but AFAIK
nobody have done something in this area yet, so if we do, this can become a
standard.
[SNIP]
> > > - 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.
> > ;-)
>
> Let me explain why I commented it (actually, commenting it made a
> huge, big mess of XineramaSupport.c): The risk that new problems
> are introduced in the *stable* 2.4.1 release has to be minimised.
Can you please explain about a mess? If I did something too interveawed
with other code, I need to know :-).
> > > 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.
>
> Well, then let's split up the function. XiParseGeometry() does
> exactly what XParseGeometry() does but with the additional
> "@<screen>" parsing. Another function could take its output as
> input and do the additional calculations. Or if that won't work,
> there should at least be an alias of the function that can be
> called like XParseGeometry().
Okay, lets do int XiParseGeometry(char *str, int *{x,y,w,h,scr}) and
XiGetGeometry(), which will do the actual calculations. The thing is that
"screen" parameter is not very useful outside XineramaSupport.c, since list
of screens shouldn't be visible outside.
The patch is attached (I'm very-very sorry for uppercase, that's my
Pegasus Mail for Dos ;-). It is cvs diff -u (similar-looking functions made
diff slightly insane, so the patch layout looks a bit inoptimal).
> BTW, if there is any risk, that rewriting the modules' placement
> code may screw things up, that part should wait until after 2.4.1.
> Cleaning up the code ca not be a priority in stable releases. Of
> course you can still include the appropriate patches in your code,
> but please comment them by ifdefs for now.
No, there's no risk at all. I changed only XParseGeometry plus related
calculations, which are always easily understandable (well, not so easily in
case of FvwmButtons ;) and hence have a very predicatble result. There'll
be no problems with #ifdef's -- I always change code in that way. ;-)
The point is not cleaning the code, but a correct operation of modules --
do you need a pager on non-primary screen?
P.S. Agreed about XiSuppClipToScreen -- I looked through modules, and only
one of them needs to pass at_x==*x and at_y==*y..
___________________________________________________________________
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.
---- File information -----------
File: XISU_DIF.GZ
Date: 28 Jul 2001, 20:10
Size: 2929 bytes.
Type: Binary
XISU_DIF.GZ
Description: Binary data
