Subject: Re: Xinerama merger -- part 1

From: Dominik Vogt <[email-masked]>
Date: Sat, 28 Jul 2001 18:15:01 +0200

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-masked] 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-masked]
Reply-To: [email-masked]

--
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-masked].
To report problems, send mail to [email-masked]

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sat, 28 Jul 2001 21:42:42 +0700

[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.
>

    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. ;-)

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-13

This 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