Re: A naive Xinerama question
Dominik Vogt fvwm-workers@fvwm.org writes:
On Tue, Aug 07, 2001 at 01:05:22PM +0200, Olivier Chapuis wrote:
BTW, I think that the change Xinerama{Enable,Disable} - Xinerama
is not very good: it is difficult to a configuration tool or a user
new to Xinerama to know if Xinerama is enabled or not.
Er, what is the big difference between
XineramaEnable
XineramaDisable
and
Xinerama on
Xinerama off
? It just saves the additional commands. And I can't think of
any fvwm command that has an off and an on version.
Iconify on
Iconify off
--
Dan Espen
444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED]
Piscataway, NJ 08854 Phone: (732) 699-5570
--
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: A naive Xinerama question
On Mon, Aug 13, 2001 at 10:27:12AM -0400, Dan Espen wrote:
Dominik Vogt fvwm-workers@fvwm.org writes:
On Tue, Aug 07, 2001 at 01:05:22PM +0200, Olivier Chapuis wrote:
BTW, I think that the change Xinerama{Enable,Disable} - Xinerama
is not very good: it is difficult to a configuration tool or a user
new to Xinerama to know if Xinerama is enabled or not.
Er, what is the big difference between
XineramaEnable
XineramaDisable
and
Xinerama on
Xinerama off
? It just saves the additional commands. And I can't think of
any fvwm command that has an off and an on version.
Iconify on
Iconify off
That's what I said. You have one command with an on and an
off option instead of Iconify and Deiconify. This makes
toggling these settings possible in the first place. My wording
was a bit unfortunate, perhaps.
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: a naive Xinerama question
By the way, Matthias, is there anything that has to be done to make FvwmGtk Xinerama compatible? Well, its been a long time since I last looked at that code... compatible is perhaps not the right term here. Any X application should be Xinerama compatible, since after all its just an extension that can be ignored. If you ask for Xinerama-aware, then the answer would probably be: make gtk+ Xinerama-aware. Which won't happen before gtk+ is extended for multiple screens/displays. Which won't happen before gtk+ 2.2. Matthias -- 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: a naive Xinerama question
On Wed, Aug 08, 2001 at 07:47:03PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Wed, 8 Aug 2001, Matthias Clasen wrote: On Tue, 7 Aug 2001, Olivier Chapuis wrote: Hello, I have a very naive Xinerama question: Is it possible to send to modules a M_NEW_SCREEN message when the mouse pointer change of screen? Technicaly it isn't possible -- X server wouldn't generate EnterScreenNotify events, since Xinerama screens look like a single large screen. But it would certainly be a useful addition to the Xinerama extension to send EnterXineramaHead and LeaveXineramaHead events - IIRC X extensions can introduce new events. If these events contain the a head number, interested applications can then easily maintain information about the set of heads the pointer is in (even for the pathological case of overlapping heads). Well, this *can* be a useful addition if we find a real case when it is needed. Than we can try to persuade Mark Vojkovich to add this functionality to X (BTW, what is interesting -- he also uses fvwm). But there must be some real, hard arguments, otherwise this definitely wouldn't pass the X Xinerama group. Well, Some users may want to have an application which is always on the current screen. Typically, if I get a double head I would like to have my FvwmPager and my WLM (TaskBar, WinList, IconMan or IconBox) always in the current screen. The solution is to run two such modules (it is the reason I added aliases support in TaskBar, WinList and IconBox recently). But a solution which seems better is that the application follows the pointer. Moreover, for some applications, running as many sticky copies of an application than screens will be not a solution to get it always on the current screen: for example with an xterm we lost the historic. So I think that an EnterScreenNotify event will be a good thing for a window manager: it will be able to manage a new/strong sticky mode for any applications. Olivier -- 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: a naive Xinerama question
On Thu, 9 Aug 2001, Olivier Chapuis wrote: Well, Some users may want to have an application which is always on the current screen. Typically, if I get a double head I would like to have my FvwmPager and my WLM (TaskBar, WinList, IconMan or IconBox) always in the current screen. The solution is to run two such modules (it is the reason I added aliases support in TaskBar, WinList and IconBox recently). But a solution which seems better is that the application follows the pointer. Moreover, for some applications, running as many sticky copies of an application than screens will be not a solution to get it always on the current screen: for example with an xterm we lost the historic. So I think that an EnterScreenNotify event will be a good thing for a window manager: it will be able to manage a new/strong sticky mode for any applications. Well, that sounds very reasonable (now I understand my mistake -- I was thinking about something similar to FvwmBacker, but for Xinerama screens, which is a nonsense ;-). We have an option to add such functionality right now, but with fvwm tracking screens itself (this is needed anyway for emulated Xinerama), and later check for real EnterScreenNotify availability in configure script. IMHO currently the best way to go is collecting various reasons for such an event, and later discuss it with X people. Looking at Xserver and libXinerama sources, I can easily work out a patch for this thingie (the server internally has a ChangeScreen event, since it has to move cursor between screens). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- 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: a naive Xinerama question
On Thu, Aug 09, 2001 at 09:37:50PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 9 Aug 2001, Olivier Chapuis wrote: Well, Some users may want to have an application which is always on the current screen. Typically, if I get a double head I would like to have my FvwmPager and my WLM (TaskBar, WinList, IconMan or IconBox) always in the current screen. The solution is to run two such modules (it is the reason I added aliases support in TaskBar, WinList and IconBox recently). But a solution which seems better is that the application follows the pointer. Moreover, for some applications, running as many sticky copies of an application than screens will be not a solution to get it always on the current screen: for example with an xterm we lost the historic. So I think that an EnterScreenNotify event will be a good thing for a window manager: it will be able to manage a new/strong sticky mode for any applications. Well, that sounds very reasonable (now I understand my mistake -- I was thinking about something similar to FvwmBacker, but for Xinerama screens, which is a nonsense ;-). We have an option to add such functionality right now, but with fvwm tracking screens itself (this is needed anyway for emulated Xinerama), and later check for real EnterScreenNotify availability in configure script. I don't think this can be solved inside fvwm to our satisfaction. Polling the mouse pointer wastes lots of CPU and tracking the pointer via MotionNotify events does not work when the pointer is grabbed. IMHO currently the best way to go is collecting various reasons for such an event, and later discuss it with X people. Looking at Xserver and libXinerama sources, I can easily work out a patch for this thingie (the server internally has a ChangeScreen event, since it has to move cursor between screens). That would be the right place to implement this functionality. 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: a naive Xinerama question
But it would certainly be a useful addition to the Xinerama extension to send EnterXineramaHead and LeaveXineramaHead events - IIRC X extensions can introduce new events. If these events contain the a head number, interested applications can then easily maintain information about the set of heads the pointer is in (even for the pathological case of overlapping heads). Well, this *can* be a useful addition if we find a real case when it is needed. Than we can try to persuade Mark Vojkovich to add this functionality to X (BTW, what is interesting -- he also uses fvwm). But there must be some real, hard arguments, otherwise this definitely wouldn't pass the X Xinerama group. All the same reasons why you want to get enter and leave events on the root window in multi-screen scenarios, I guess. Of course, the application with the strongest interest in such information is the window manager, but toolkits could also use it as a low-overhead way to find the necessary information for e.g. restricting menus to be completely onscreen (or rather onxineramascreen). In fact, I would thing that enter/leave notification would be a very natural feature and I can't think of any possible reasons for the X Xinerama group to not accept it. Matthias -- 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: A naive Xinerama question
On Tue, 7 Aug 2001, Olivier Chapuis wrote: Hello, I have a very naive Xinerama question: Is it possible to send to modules a M_NEW_SCREEN message when the mouse pointer change of screen? Technicaly it isn't possible -- X server wouldn't generate EnterScreenNotify events, since Xinerama screens look like a single large screen. If this behaviour is really needed, fvwm itself should always check if XineramaScreen(curx,cury)!=XineramaScreen(oldx,oldy), which can be time consuming. And there's another pitfall -- screens may overlap, so that screen where the pointer on concept becomes somewhat dubious (but that's a pathological case, and we use this concept anyway for determining a rectangle to clip menus etc. to). BTW, Olivier, can you please tell where this behaviour can be useful? I tried to imagine such situations with no results, but something tells me they *must* exist. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- 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: A naive Xinerama question
On Tue, Aug 07, 2001 at 01:05:22PM +0200, Olivier Chapuis wrote:
BTW, I think that the change Xinerama{Enable,Disable} - Xinerama
is not very good: it is difficult to a configuration tool or a user
new to Xinerama to know if Xinerama is enabled or not.
Er, what is the big difference between
XineramaEnable
XineramaDisable
and
Xinerama on
Xinerama off
? It just saves the additional commands. And I can't think of
any fvwm command that has an off and an on version. On the
other hand it makes module configuration a lot easier. Fvwm can
simply send the whole string after Xinerama to the module which
in turn passes it to a Xinerama library function to configure
itself. Also, many commands already use the boolean argument
type, so why not this one?
With
Xinerama{Enable,Disable} we know where we go as with the Xinerama
command even an experimented user should try a command or an action
to see if Xinerama is enabled or not and predict the effect of this
command.
It almost never makes sense to turn off Xinerama anyway. If there
is only one screen it is a no-op. If you have more than one
screen, not using Xinerama support is a pain. The only situation
I can think of where this is not desirable is with a very big,
tiled screen composed of many monitors, e.g. on a trade fair. In
this case we can expect that the tech people are able to read the
man page.
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: a naive Xinerama question
On Wed, 8 Aug 2001, Matthias Clasen wrote: On Tue, 7 Aug 2001, Olivier Chapuis wrote: Hello, I have a very naive Xinerama question: Is it possible to send to modules a M_NEW_SCREEN message when the mouse pointer change of screen? Technicaly it isn't possible -- X server wouldn't generate EnterScreenNotify events, since Xinerama screens look like a single large screen. But it would certainly be a useful addition to the Xinerama extension to send EnterXineramaHead and LeaveXineramaHead events - IIRC X extensions can introduce new events. If these events contain the a head number, interested applications can then easily maintain information about the set of heads the pointer is in (even for the pathological case of overlapping heads). Well, this *can* be a useful addition if we find a real case when it is needed. Than we can try to persuade Mark Vojkovich to add this functionality to X (BTW, what is interesting -- he also uses fvwm). But there must be some real, hard arguments, otherwise this definitely wouldn't pass the X Xinerama group. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- 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]
