On Sat, Jul 28, 2001 at 09:42:42PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
> 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.
Writing a standard for this would clearly be something that should
go into the "Enhanced Window Manager Hints" spec. In any case,
it's much better to do it as a root window property. But I since
nobody is writing applications especially for fvwm, any property
we define would not be used anyway.
> > 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.
No, it shouldn't be visible outside. Don't return it through the
interface. If you want a function that returns more than x/y/w/h,
don't call it ...ParseGeometry(). This will just be confusing. As
far as I can see the knowledge of the screen is not needed
awterwards. If you need that information to call another
function, you can write an internal variant of the
...ParseGeometry() function that returns screen numbers too. Then
call it from your XiWMGeometry() function and from
XiParseGeometry(). But you should not change standard interfaces.
> The patch is attached (I'm very-very sorry for uppercase, that's my
> Pegasus Mail for Dos ;-).
Eeeek!
> It is cvs diff -u (similar-looking functions made
> diff slightly insane, so the patch layout looks a bit inoptimal).
Don't care
> ...
> The point is not cleaning the code, but a correct operation of modules --
> do you need a pager on non-primary screen?
I don't quit understand the question. Of course I'd usually
prefer the pager on the primary screen, but perhaps I wnat one on
both screens.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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]
