Re: Xinerama merger -- part 1
On 28 Jul 01 at 18:15, [EMAIL PROTECTED] wrote: [SNIP] 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. What I meant is that introducing Xinerama support into fvwm2 binary, but leaving modules still use XParseGeometry() is inconsistent -- the pieces of code responsible for window's placement should be modified too (sorry for my not-so-perfect english ;-). Otherwise in the case of the following layout: +--++ | 1024 |800 | | 768 |600 | | ++ +--+ too many things will tend to place themselves into the void. ___ 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]
Re: Xinerama merger -- part 1
On Fri, Jul 27, 2001 at 09:35:49PM +0700, Dmitry Yu. Bolkhovityanov wrote:
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.
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.
- 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.
Another one of the things that nobody has the time and leisure to
do. The common practice is that everybody formats his code pieces
as he likes. Whenever one of the more active developers works a
lot with a certain piece of code (mostly me) he is free to
reformat that code as he likes. I think there would be a lot of
potential for an extensive religios war about brace, whitepace and
comment placement if we really tried to write something down :-)
- 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.
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
Re: Xinerama merger -- part 1
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]
Re: Xinerama merger -- part 1
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).
Re: Xinerama merger -- part 1
On Thu, Jul 26, 2001 at 05:43:39PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
Hi!
That's part 1 of XineramaSupport v2 merger. It contains
libs/XineramaSupport.[ch] as drop-in replacements. Next part will be
configure script, followed by modules.
The only change required is to fvwm/menus.c -- to use
XiSuppClipToScreenAt() instead of XiSuppClipToScreen() (the first of them
appeared in XiSupp after february version).
I will start applying your patches as soon as possible. Since my
mother pays me a visit this weekend I can't promise that I'll have
the time.
Dominik, I have a question/correction regarding your changes to XiSupp.c.
The XiSuppDisable() was intended as a mechanism to hard-disable Xinerama,
while XiSuppSetState() -- to turn it on/off on the fly. As I understood,
you changed XiSuppSetState() to be internal call, while
XiSupp{Enable,Disable} are used as previously XiSuppSetState(). Am I right?
Yes. I did not understand this logic and I did not want that the
interface of XiSetState() was visible outside the module because
it has an interface that can be called in a way that would crash
fvwm later. I think a simple on/off call is enough. Also, it is
more flexible if you can't disable Xinerama support completely.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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]
Re: Xinerama merger -- part 1
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]
Xinerama merger -- part 1
Hi!
That's part 1 of XineramaSupport v2 merger. It contains
libs/XineramaSupport.[ch] as drop-in replacements. Next part will be
configure script, followed by modules.
The only change required is to fvwm/menus.c -- to use
XiSuppClipToScreenAt() instead of XiSuppClipToScreen() (the first of them
appeared in XiSupp after february version).
Dominik, I have a question/correction regarding your changes to XiSupp.c.
The XiSuppDisable() was intended as a mechanism to hard-disable Xinerama,
while XiSuppSetState() -- to turn it on/off on the fly. As I understood,
you changed XiSuppSetState() to be internal call, while
XiSupp{Enable,Disable} are used as previously XiSuppSetState(). Am I right?
___
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: FXNR_P1.TGZ
Date: 26 Jul 2001, 17:17
Size: 7298 bytes.
Type: Binary
FXNR_P1.TGZ
Description: Binary data
