Committed Xinerama cleanup and a restructuring patch
Just committed 1) The Xinerama cleanup. 2) A big patch that makes move_resize.c and some related places in other files use the types position, size_rect and rectangle. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [PATCH/RFC] Xinerama
On Tue, Nov 23, 2021 at 01:44:52AM +0100, Dominik Vogt wrote: > Menu foomenu monitor c c > > Should place the menu in the middle of the current monitor. Or Menu foomenu c-20 c+30 should place it 20% of the monitor size left from the center and 30% below the center. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [PATCH/RFC] Xinerama
On Mon, Nov 22, 2021 at 11:52:38PM +, Thomas Adam wrote: > On Tue, Nov 23, 2021 at 12:31:15AM +0100, Dominik Vogt wrote: > > The old manmage said: > > > > XineramaRoot > > > > the root window of the whole Xinerama screen. Equivalent to > > "root" when Xinerama is not used. > > > > Can you please restate that for me? What is "whole Xinerama > > screen" in xrandr terms? > > >From a quick scan of the code in menus.c where xineramaroot is being used, > it's not entirely clear to me, In the past it referenced the current Xinerama screen, not the whole root window. When a menu is placed the code needs a reference rectangle to calculate the menu position. It can be relative to the pointer, to a window, to the root window, to a monitor etc. > but if this option is meant to do what I think > it is, then this would be taking the width/height of the monitor the > pointer/window is on, rather than referencing the width/height of the entire > root window. That would be correct. Renamed it to "monitor" and "fMonitorContext". There's only one place in the code that evaluates the flag, and that looks fishy. Can you test it? Menu foomenu monitor c c Should place the menu in the middle of the current monitor. The code is on the dv/devel branch (you may not want the top commit on that branch). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [PATCH/RFC] Xinerama
On Tue, Nov 23, 2021 at 12:31:15AM +0100, Dominik Vogt wrote: > The old manmage said: > > XineramaRoot > > the root window of the whole Xinerama screen. Equivalent to > "root" when Xinerama is not used. > > Can you please restate that for me? What is "whole Xinerama > screen" in xrandr terms? >From a quick scan of the code in menus.c where xineramaroot is being used, it's not entirely clear to me, but if this option is meant to do what I think it is, then this would be taking the width/height of the monitor the pointer/window is on, rather than referencing the width/height of the entire root window. Kindly, Thomas
Re: [PATCH/RFC] Xinerama
On Mon, Nov 22, 2021 at 10:46:20PM +, Thomas Adam wrote:
> On Mon, Nov 22, 2021 at 11:26:53PM +0100, Dominik Vogt wrote:
> > On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> > > Patch attached. Can you please double check and fill in the gaps?
> > > (see comments belo).
> > >
> > > > > ./fvwm/menus.c: fXineramaRoot = False;
> > > > > ./fvwm/menus.c: else if (StrEquals(tok,"xineramaroot"))
> > >
> > >
> > > Not sure what the right name of the option and the flag variable
> > > should be. There's only a placeholder in the man page either.
>
> Making that change would be syntactically breaking people's configs, but... I
> bet it's a rarely-used option that should just be "screenroot" or something.
It can have two names, a real one and still "xineramaroot" for
compatibility. Screenroot? Rootscreen? Just tell me a good
name.
The old manmage said:
XineramaRoot
the root window of the whole Xinerama screen. Equivalent to
"root" when Xinerama is not used.
Can you please restate that for me? What is "whole Xinerama
screen" in xrandr terms?
> > > > > ./perllib/FVWM/Commands.pm: descr => q{Move a window to
> > > > > another Xinerama screen},
> > >
> > > [MOVE_TO_SCREEN]
> > > This one should be just renamed to just "screen"?
>
> Yes please.
Good. It's already part of the patch.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: [PATCH/RFC] Xinerama
On Mon, Nov 22, 2021 at 11:26:53PM +0100, Dominik Vogt wrote:
> On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> > Patch attached. Can you please double check and fill in the gaps?
> > (see comments belo).
> >
> > > > ./fvwm/menus.c: fXineramaRoot = False;
> > > > ./fvwm/menus.c: else if (StrEquals(tok,"xineramaroot"))
> >
> >
> > Not sure what the right name of the option and the flag variable
> > should be. There's only a placeholder in the man page either.
Making that change would be syntactically breaking people's configs, but... I
bet it's a rarely-used option that should just be "screenroot" or something.
> > > > ./perllib/FVWM/Commands.pm: descr => q{Move a window to
> > > > another Xinerama screen},
> >
> > [MOVE_TO_SCREEN]
> > This one should be just renamed to just "screen"?
Yes please.
> Ping.
Sorry, I didn't spot this earlier.
Kindly,
Thomas
Re: [PATCH/RFC] Xinerama
On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> Patch attached. Can you please double check and fill in the gaps?
> (see comments belo).
>
> > > ./fvwm/menus.c: fXineramaRoot = False;
> > > ./fvwm/menus.c: else if (StrEquals(tok,"xineramaroot"))
>
>
> Not sure what the right name of the option and the flag variable
> should be. There's only a placeholder in the man page either.
>
> > > ./perllib/FVWM/Commands.pm: descr => q{Move a window to
> > > another Xinerama screen},
>
> [MOVE_TO_SCREEN]
> This one should be just renamed to just "screen"?
Ping.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
[PATCH/RFC] Xinerama
On Sat, Nov 20, 2021 at 10:24:46PM +, Thomas Adam wrote:
> On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote:
> > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote:
> > >
> > > > Is Xinerama still useful for anything or can we remove it?
> > > >
> > > It has already been removed. Where are you seeing references to it?
Patch attached. Can you please double check and fill in the gaps?
(see comments belo).
> > ./fvwm/menus.c: fXineramaRoot = False;
> > ./fvwm/menus.c: else if (StrEquals(tok,"xineramaroot"))
Not sure what the right name of the option and the flag variable
should be. There's only a placeholder in the man page either.
> > ./perllib/FVWM/Commands.pm: descr => q{Move a window to another
> > Xinerama screen},
[MOVE_TO_SCREEN]
This one should be just renamed to just "screen"?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 03149ce8658894f22e3c5e17cc8d981bb9563ec8 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 21 Nov 2021 00:27:00 +0100
Subject: [PATCH 1/4] Remove Xinerama leftovers.
---
bin/fvwm-config.in | 6 +++---
doc/fvwm3_manpage_source.adoc| 5 -
fvwm/add_window.c| 3 +--
fvwm/commands.h | 10 -
fvwm/functable.c | 2 +-
fvwm/fvwm.h | 8 +++
fvwm/menuparameters.h| 6 ++
fvwm/menus.c | 27 +++
fvwm/module_interface.h | 1 -
fvwm/move_resize.c | 15 ++---
fvwm/placement.c | 4 ++--
fvwm/screen.h| 1 -
fvwm/style.c | 24 ++---
fvwm/style.h | 8 +++
fvwm/update.c| 6 --
fvwm/windowlist.c| 2 +-
libs/FTips.c | 2 +-
libs/defaults.h | 6 --
modules/FvwmButtons/FvwmButtons.h| 1 -
modules/FvwmForm/FvwmForm.c | 17 ---
perllib/FVWM/Commands.pm | 32 +---
perllib/FVWM/Tracker/GlobalConfig.pm | 7 +++---
22 files changed, 59 insertions(+), 134 deletions(-)
diff --git a/bin/fvwm-config.in b/bin/fvwm-config.in
index 77ea48a3..4ca9edce 100644
--- a/bin/fvwm-config.in
+++ b/bin/fvwm-config.in
@@ -90,9 +90,9 @@ with_shape=@with_shape@
with_shm=@with_shm@
with_sm=@with_sm@
with_xcursor=@with_xcursor@
-with_xinerama=@with_xinerama@
with_xft=@with_xft@
with_xpm=@with_xpm@
+with_xrandr=@with_xinerama@
with_xrender=@with_xrender@
while test $# -gt 0; do
@@ -162,9 +162,9 @@ while test $# -gt 0; do
test "$with_shm"= "yes" && echo "shm"
test "$with_sm" = "yes" && echo "sm"
test "$with_xcursor"= "yes" && echo "xcursor"
- test "$with_xinerama" = "yes" && echo "xinerama"
test "$with_xft"= "yes" && echo "xft"
test "$with_xpm"= "yes" && echo "xpm"
+ test "$with_xrandr" = "yes" && echo "xrandr"
test "$with_xrender"= "yes" && echo "xrender"
;;
@@ -210,9 +210,9 @@ while test $# -gt 0; do
echo " sm (session management): $with_sm"
echo " rsvg (SVG icons and images): $with_rsvg"
echo " xcursor (ARGB/animated cursors): $with_xcursor"
- echo " xinerama (multi-head): $with_xinerama"
echo " xft (FreeType anti-alias font): $with_xft"
echo " xpm: $with_xpm"
+ echo " xrandr (multi-head): $with_xrand"
echo " xrender (XFree86 Xrender extention): $with_xrender"
;;
diff --git a/doc/fvwm3_manpage_source.adoc b/doc/fvwm3_manpage_source.adoc
index 42187d14..dee9a0e0 100644
--- a/doc/fvwm3_manpage_source.adoc
+++ b/doc/fvwm3_manpage_source.adoc
@@ -2264,6 +2264,9 @@ The _context-rectangle_ can be one of:
_Root_:::
the root window of the current screen.
+
+_ScreenRoot_:::
+ !!!???
++
_Mouse_:::
a 1x1 rectangle at the mouse position.
+
@@ -6130,7 +6133,7 @@ it is still possible to move or resize windows across the edge of the
current screen. See also *EdgeThickness*.
The option _EdgeMoveResistance_ makes it easier to place a window
-directly adjacent to the screen's or xinerama screen's border. It
+directly adjacent to the screen's border. It
takes one or two parameters. The first parameter tells how many pixels
over the edge of the screen a window's edge must move before it
actually moves partia
Re: Xinerama
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote: > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > > > Is Xinerama still useful for anything or can we remove it? > > > > > It has already been removed. Where are you seeing references to it? > > Everywhere. I'll remove the junk on the parser branch. > > $ rgrep -i xinerama . 2> /dev/null > ./libs/defaults.h:/*** Xinerama ***/ > ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on > by default */ > ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig" These can go, and the corresponding callers in FvwmForm can be changed. This looks to be the mechanism module used to use to register Xinerama interest. > ./libs/FTips.c: fscreen_scr_arg *fsarg = NULL; /* for now no xinerama > support */ That comment is misleading and can be changed, > ./modules/FvwmForm/FvwmForm.c: if (strncasecmp(buf, XINERAMA_CONFIG_STRING, > ./modules/FvwmForm/FvwmForm.c: > sizeof(XINERAMA_CONFIG_STRING)-1) == 0) > ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + > sizeof(XINERAMA_CONFIG_STRING)-1); > ./modules/FvwmForm/FvwmForm.c:buf, XINERAMA_CONFIG_STRING, > sizeof(XINERAMA_CONFIG_STRING)-1) > ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + > sizeof(XINERAMA_CONFIG_STRING)-1); See above. > ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args); That's just a function declaration without an implementation and can be removed. > ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly > adjacent to the screen's or xinerama screen's border. It > ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly > adjacent to the screen's or xinerama screen's border. It rerere cache from git so will ignore. > ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama > screen's border. It > ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs > border. It > ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's > border. It > ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama > screen\(cqs border. It > ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama > screen's border. It These can change to either mention RandR, or just "screen". > ./fvwm/windowlist.c: * because it sets the xinerama screen origin */ > ./fvwm/add_window.c: fw->edge_resistance_xinerama_move = > ./fvwm/add_window.c: pstyle->edge_resistance_xinerama_move; > ./fvwm/move_resize.c: * in case Xinerama is used. */ > ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */ > ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) Funtionally now referencing RandR and are poorly named as xinerama isn't used. > ./fvwm/style.c: if (add_style->flags.has_edge_resistance_xinerama_move) > ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE( > ./fvwm/style.c: > SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style)); > ./fvwm/style.c: unsigned has_xinerama_move; > ./fvwm/style.c: has_xinerama_move = 0; > ./fvwm/style.c: has_xinerama_move = 1; > ./fvwm/style.c: has_xinerama_move = 0; > ./fvwm/style.c: > ps->flags.has_edge_resistance_xinerama_move = > ./fvwm/style.c: has_xinerama_move; > ./fvwm/style.c: > ps->flag_mask.has_edge_resistance_xinerama_move = 1; > ./fvwm/style.c: > ps->change_mask.has_edge_resistance_xinerama_move = 1; > ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, > val[1]); > ./fvwm/fvwm.h:char*IconScreen; /* Xinerama > screen */ > ./fvwm/fvwm.h:unsigned has_edge_resistance_xinerama_move : 1; > ./fvwm/fvwm.h:int edge_resistance_xinerama_move; > ./fvwm/fvwm.h:int edge_resistance_xinerama_move; As above. This just needs renaming. > ./fvwm/commands.h:F_XINERAMA, > ./fvwm/commands.h:F_XINERAMAPRIMARYSCREEN, > ./fvwm/commands.h:F_XINERAMASLS, > ./fvwm/co
Re: Xinerama
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote: > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > > > Is Xinerama still useful for anything or can we remove it? > > > > > It has already been removed. Where are you seeing references to it? > > Everywhere. I'll remove the junk on the parser branch. No sorry, too complex for me, and I don't know the new implementation. The code in menus.c, move_resize.c etc is non-trivial and maybe still necessary. But wen can't do it with the parser branch pending. It would cause too many conflicts. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Xinerama
On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > Is Xinerama still useful for anything or can we remove it? > > > It has already been removed. Where are you seeing references to it? Everywhere. I'll remove the junk on the parser branch. $ rgrep -i xinerama . 2> /dev/null ./libs/defaults.h:/*** Xinerama ***/ ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on by default */ ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig" ./libs/FTips.c: fscreen_scr_arg *fsarg = NULL; /* for now no xinerama support */ ./modules/FvwmForm/FvwmForm.c: if (strncasecmp(buf, XINERAMA_CONFIG_STRING, ./modules/FvwmForm/FvwmForm.c:sizeof(XINERAMA_CONFIG_STRING)-1) == 0) ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + sizeof(XINERAMA_CONFIG_STRING)-1); ./modules/FvwmForm/FvwmForm.c: buf, XINERAMA_CONFIG_STRING, sizeof(XINERAMA_CONFIG_STRING)-1) ./modules/FvwmForm/FvwmForm.c: FScreenConfigureModule(buf + sizeof(XINERAMA_CONFIG_STRING)-1); ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args); ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly adjacent to the screen's or xinerama screen's border. It ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs border. It ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs border. It ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama screen's border. It ./fvwm/windowlist.c: * because it sets the xinerama screen origin */ ./fvwm/add_window.c:fw->edge_resistance_xinerama_move = ./fvwm/add_window.c:pstyle->edge_resistance_xinerama_move; ./fvwm/move_resize.c:* in case Xinerama is used. */ ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */ ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) ./fvwm/style.c: if (add_style->flags.has_edge_resistance_xinerama_move) ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE( ./fvwm/style.c: SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style)); ./fvwm/style.c: unsigned has_xinerama_move; ./fvwm/style.c: has_xinerama_move = 0; ./fvwm/style.c: has_xinerama_move = 1; ./fvwm/style.c: has_xinerama_move = 0; ./fvwm/style.c: ps->flags.has_edge_resistance_xinerama_move = ./fvwm/style.c: has_xinerama_move; ./fvwm/style.c: ps->flag_mask.has_edge_resistance_xinerama_move = 1; ./fvwm/style.c: ps->change_mask.has_edge_resistance_xinerama_move = 1; ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, val[1]); ./fvwm/fvwm.h: char*IconScreen; /* Xinerama screen */ ./fvwm/fvwm.h: unsigned has_edge_resistance_xinerama_move : 1; ./fvwm/fvwm.h: int edge_resistance_xinerama_move; ./fvwm/fvwm.h: int edge_resistance_xinerama_move; ./fvwm/commands.h: F_XINERAMA, ./fvwm/commands.h: F_XINERAMAPRIMARYSCREEN, ./fvwm/commands.h: F_XINERAMASLS, ./fvwm/commands.h: F_XINERAMASLSSCREENS, ./fvwm/commands.h: F_XINERAMASLSSIZE, ./fvwm/commands.h:void CMD_Xinerama(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaPrimaryScreen(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSls(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSlsScreens(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSlsSize(F_CMD_ARGS); ./fvwm/screen.h:unsigned has_xinerama_state_changed : 1; ./fvwm/module_interface.h:void broadcast_xinerama_state(void); ./fvwm/placement.c: * Xinerama screen. 1: The intuitive way giving a geometry ./fvwm/placement.c: * 2: Do NOT specify a Xinerama screen (or specify it to be ./fvwm/functable.c: /* - Move a window to another Xinerama screen */ ./fvwm/style.h:#define SGET_EDGE_RESISTANCE_XINERAMA_MOVE(s) \ ./fvwm/style.h: ((s).edge_resistance_xinerama_move) ./fvwm/style.h:#define SSET_EDGE_RESISTANCE_XINERAMA_MOVE(s,x) \ ./fvwm/style.h: ((s).edge_resistance_xinerama_move = (x)) ./fvwm/menuparameters.h:/* A position on the Xinerama screen on whic
Xinerama
Is Xinerama still useful for anything or can we remove it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
CVS domivogt: * Corrected a typo and rephrased some Xinerama docs.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt05/10/14 14:43:00 Modified files: fvwm : fvwm.1.in Log message: * Corrected a typo and rephrased some Xinerama docs.
CVS domivogt: * Fixed Xinerama crash.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt04/09/06 05:08:59 Modified files: . : ChangeLog libs : FScreen.c Log message: * Fixed Xinerama crash. -- 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]
CVS domivogt: * Fixed Solaris Xinerama configure test (nested AC_CHECK_LIB calls don't work)
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt04/08/26 04:40:42 Modified files: . : ChangeLog NEWS configure.in libs : FScreen.c Log message: * Fixed Solaris Xinerama configure test (nested AC_CHECK_LIB calls don't work) * Cleaned up the ifdef hell in FScreen.c; all code is compiled all the time; please don't put code in ifdefs. -- 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: Solaris Xinerama support
On Fri, Aug 20, 2004 at 09:32:35AM -0400, Chris Ross wrote: Dan Espen wrote: If the #define'd stuff is only used on Solaris, when the header isn't there, and the library support is there, I'd say that was OK. Yup. That's how it's done. Only if the libXinerama stuff isn't found will it look for Solaris' calls, and only if those are found will it look for the header. If the header is found, the few lines (to replace the header) I added don't get used. The following should be the full diff against CVS HEAD for this patch. Thanks for all your help! - Chris Index: configure.in === RCS file: /home/cvs/fvwm/fvwm/configure.in,v retrieving revision 1.294 diff -u -u -r1.294 configure.in --- configure.in 23 May 2004 16:20:23 - 1.294 +++ configure.in 20 Aug 2004 13:26:58 - @@ -298,8 +298,18 @@ $UNSET ac_cv_lib_Xinerama_XineramaIsActive AC_CHECK_LIB(Xinerama, XineramaIsActive, with_xinerama=yes; Xinerama_LIBS=-lXinerama; AC_DEFINE(HAVE_XINERAMA), +AC_CHECK_LIB(Xext, XineramaGetState, + [ AC_DEFINE(HAVE_XINERAMA) AC_DEFINE(HAVE_SOLARIS_XINERAMA) + with_xinerama=yes; Xinerama_LIBS=-lXext + my_CPPFLAGS=$CPPFLAGS; CPPFLAGS=$X_CPPFLAGS $CPPFLAGS + my_hdr=X11/extensions/xinerama.h + AC_CHECK_HEADER($my_hdr, AC_DEFINE(HAVE_SOLARIS_XINERAMA_H) + problem_xinerama= (Using Solaris Xinerama calls), + problem_xinerama= (Failed to find Sun's $my_hdr)) + CPPFLAGS=$my_CPPFLAGS], with_xinerama=no; Xinerama_LIBS= problem_xinerama=: Failed to detect libXinerama, +[$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS]), [$X_LIBS $X_PRE_LIBS -lXext -lX11 $X_EXTRA_LIBS]) fi AC_SUBST(Xinerama_LIBS) Note that this nesting of AC_CHECK_LIB calls did not work with my autoconf/automake versions. I have split it in two separate calls. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpNYa7L80UQF.pgp Description: PGP signature
Re: Solaris Xinerama support
Dominik Vogt [EMAIL PROTECTED] writes: Note that this nesting of AC_CHECK_LIB calls did not work with my autoconf/automake versions. I have split it in two separate calls. Darn. And I tested this on Linux and Solaris. I woke up in the middle of the night and it dawned on me that I never updated NEWS. I figured no one would notice and I could take care of it when I got up. -- Dan Espen E-mail: [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: Solaris Xinerama support
On Thu, Aug 26, 2004 at 06:48:22AM -0400, Dan Espen wrote: I woke up in the middle of the night and it dawned on me that I never updated NEWS. I figured no one would notice and I could take care of it when I got up. Heh, now *that*'s what I call being passionate about one's work. :) -- Thomas Adam -- Quis custodiet ipsos custodes? -- 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: Solaris Xinerama support
On Thu, Aug 26, 2004 at 06:48:22AM -0400, Dan Espen wrote: Dominik Vogt [EMAIL PROTECTED] writes: Note that this nesting of AC_CHECK_LIB calls did not work with my autoconf/automake versions. I have split it in two separate calls. Darn. And I tested this on Linux and Solaris. They changed something with quoting in autoconf/automake a while ago. Unfortunately you have to test with the old and new auto* versions to make sure some things in configure work fine. I woke up in the middle of the night and it dawned on me that I never updated NEWS. I figured no one would notice and I could take care of it when I got up. If all else fails, I will notice missing NEWS entries sooner or later ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpbpOM2yel87.pgp Description: PGP signature
Re: Solaris Xinerama support
Thanks Dominik. Dominik Vogt wrote: They changed something with quoting in autoconf/automake a while ago. Unfortunately you have to test with the old and new auto* versions to make sure some things in configure work fine. Odd. It worked for me, too, using the same version of autoconf that'd previously generated the configure. Guess that must've changed on your system and not mine. Thanks for fixing it! There were a couple issues with your changes to libs/FScreen.c. I don't know that I agree with the all code should be compiled opinion, but that's certainly your call to make. And the #ifdef'd code is now more sensible than it was, and than I'd made it. Thanks. But, there was one typo (capitalization error), and one error in the #def's. Solaris' xinerama.h does *not* define XineramaScreenInfo, since Solaris' xinerama system API is *completely* different. I just moved the relevant #def out one level. A patch to libs/FScreen.c is attached. It will now link both with and without the Solaris xinerama.h header. Thanks again! - Chris Index: libs/FScreen.c === RCS file: /home/cvs/fvwm/fvwm/libs/FScreen.c,v retrieving revision 1.24 diff -u -r1.24 FScreen.c --- libs/FScreen.c 26 Aug 2004 09:40:42 - 1.24 +++ libs/FScreen.c 26 Aug 2004 15:52:53 - @@ -73,10 +73,10 @@ # define FScreenHaveXinerama 1 # ifdef HAVE_SOLARIS_XINERAMA # define FScreenHaveSolarisXinerama 1 +# define FSCREEN_NEED_SCREENINFO # ifdef HAVE_SOLARIS_XINERAMA_H # include X11/extensions/xinerama.h # else -# define FSCREEN_NEED_SCREENINFO # define FSCREEN_NEED_SOLARIS_PROTOTYPES # endif # else @@ -114,7 +114,7 @@ #if FScreenHaveXinerama # if FScreenHaveSolarisXinerama # define XineramaQueryExtension(d,b,c) 1 /* Lie, for now */ -# define XineramaIsActive(d) Xineramagetstate((d),0) +# define XineramaIsActive(d) XineramaGetState((d),0) # endif #else # define XineramaQueryExtension(da, b, c) 0
Re: Solaris Xinerama support
Dan Espen wrote:
If the #define'd stuff is only used on Solaris, when the header
isn't there, and the library support is there, I'd say that was
OK.
Yup. That's how it's done. Only if the libXinerama stuff
isn't found will it look for Solaris' calls, and only if those
are found will it look for the header. If the header is found,
the few lines (to replace the header) I added don't get used.
The following should be the full diff against CVS HEAD for
this patch. Thanks for all your help!
- Chris
Index: configure.in
===
RCS file: /home/cvs/fvwm/fvwm/configure.in,v
retrieving revision 1.294
diff -u -u -r1.294 configure.in
--- configure.in23 May 2004 16:20:23 - 1.294
+++ configure.in20 Aug 2004 13:26:58 -
@@ -298,8 +298,18 @@
$UNSET ac_cv_lib_Xinerama_XineramaIsActive
AC_CHECK_LIB(Xinerama, XineramaIsActive,
with_xinerama=yes; Xinerama_LIBS=-lXinerama; AC_DEFINE(HAVE_XINERAMA),
+AC_CHECK_LIB(Xext, XineramaGetState,
+ [ AC_DEFINE(HAVE_XINERAMA) AC_DEFINE(HAVE_SOLARIS_XINERAMA)
+ with_xinerama=yes; Xinerama_LIBS=-lXext
+ my_CPPFLAGS=$CPPFLAGS; CPPFLAGS=$X_CPPFLAGS $CPPFLAGS
+ my_hdr=X11/extensions/xinerama.h
+ AC_CHECK_HEADER($my_hdr, AC_DEFINE(HAVE_SOLARIS_XINERAMA_H)
+ problem_xinerama= (Using Solaris Xinerama calls),
+ problem_xinerama= (Failed to find Sun's $my_hdr))
+ CPPFLAGS=$my_CPPFLAGS],
with_xinerama=no; Xinerama_LIBS=
problem_xinerama=: Failed to detect libXinerama,
+[$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS]),
[$X_LIBS $X_PRE_LIBS -lXext -lX11 $X_EXTRA_LIBS])
fi
AC_SUBST(Xinerama_LIBS)
Index: acconfig.h
===
RCS file: /home/cvs/fvwm/fvwm/acconfig.h,v
retrieving revision 1.72
diff -u -u -r1.72 acconfig.h
--- acconfig.h 8 Jul 2004 10:08:09 - 1.72
+++ acconfig.h 20 Aug 2004 13:26:58 -
@@ -32,6 +32,14 @@
/* Define if Xinerama library is used. */
#undef HAVE_XINERAMA
+/* Define if Solaris' Xinerama calls are being used. */
+/* (Solaris 7 11/99 and later) */
+#undef HAVE_SOLARIS_XINERAMA
+
+/* Define if Solaris' X11/extensions/xinerama.h header is provided. */
+/* (Solaris 9 and later) */
+#undef HAVE_SOLARIS_XINERAMA_H
+
/* Define if Xrender library is used. */
#undef HAVE_XRENDER
Index: fvwm/fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.368
diff -u -u -r1.368 fvwm.c
--- fvwm/fvwm.c 15 Jul 2004 13:12:28 - 1.368
+++ fvwm/fvwm.c 20 Aug 2004 13:26:59 -
@@ -1312,6 +1312,9 @@
strcat(support_str, Bidi text,);
#endif
#ifdef HAVE_XINERAMA
+# ifdef HAVE_SOLARIS_XINERAMA
+ strcat(support_str, [Solaris' odd-ball]);
+# endif
strcat(support_str, Xinerama,);
#endif
#ifdef HAVE_XRENDER
Index: libs/FScreen.c
===
RCS file: /home/cvs/fvwm/fvwm/libs/FScreen.c,v
retrieving revision 1.22
diff -u -u -r1.22 FScreen.c
--- libs/FScreen.c 17 Mar 2004 14:42:54 - 1.22
+++ libs/FScreen.c 20 Aug 2004 13:26:59 -
@@ -69,8 +69,62 @@
#include PictureBase.h
#ifdef HAVE_XINERAMA
-#define FScreenHaveXinerama 1
-#include X11/extensions/Xinerama.h
+# define FScreenHaveXinerama 1
+# ifdef HAVE_SOLARIS_XINERAMA
+# ifdef HAVE_SOLARIS_XINERAMA_H
+# include X11/extensions/xinerama.h
+# else
+/* Copied from Solaris 9's X11/extensions/xinerama.h */
+#defineMAXFRAMEBUFFERS 16
+Bool XineramaGetState(Display*, int);
+Status XineramaGetInfo(Display*, int, XRectangle*, unsigned char*, int*);
+Status XineramaGetCenterHint(Display*, int, int*, int*);
+# endif /* HAVE_SOLARIS_XINERAMA_H */
+typedef struct
+{
+ int screen_number;
+ short x_org;
+ short y_org;
+ short width;
+ short height;
+} XineramaScreenInfo;
+# define XineramaIsActive(d) XineramaGetState((d),0)
+# define XineramaQueryScreens(d,b)solaris_XineramaQueryScreens((d),(b))
+# define XineramaQueryExtension(d,b,c)1 /* Lie, for now */
+static XineramaScreenInfo *
+solaris_XineramaQueryScreens(Display *d, int *xin_nscreens)
+{
+ XineramaScreenInfo *screens = NULL;
+ XRectangle monitors[MAXFRAMEBUFFERS];
+ unsigned char hints[16];
+
+ int result = XineramaGetInfo(d, DefaultScreen(d), monitors, hints,
+xin_nscreens);
+ if (result)
+ {
+ int m;
+
+ screens = (XineramaScreenInfo
*)malloc(sizeof(XineramaScreenInfo) * (*xin_nscreens));
+ for (m = 0; m *xin_nscreens; ++m)
+ {
+ screens[m].screen_number = m;
+ screens[m].x_org = monitors[m].x;
+ screens[m].y_org = monitors[m].y;
+ screens[m
Re: Solaris Xinerama support
Dan Espen wrote: I guess I can answer my own question, it configures but doesn't compile: gcc -DHAVE_CONFIG_H -I. -I../../version-2_5_11/libs -I.. -I../../version-2_5_11 -I/opt/public/include -I/usr/openwin/include -I/opt/public/include -g -O2 -Wall -Wno-implicit-int -c ../../version-2_5_11/libs/FScreen.c ../../version-2_5_11/libs/FScreen.c:74: X11/extensions/xinerama.h: No such file or directory You can send any additional patches to the list. I'm not sure what to do to fix that. I suppose there may be some way to check for the header in configure, and if it's not present (Solaris 7 11/99, or Solaris 8) I could just sub in the contents. They're quite minimal. This seem to objectionable to people? - Chris -- 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: Solaris Xinerama support
Chris Ross [EMAIL PROTECTED] writes: Dan Espen wrote: I guess I can answer my own question, it configures but doesn't compile: gcc -DHAVE_CONFIG_H -I. -I../../version-2_5_11/libs -I.. -I../../version-2_ 5_11 -I/opt/public/include -I/usr/openwin/include -I/opt/public/include -g -O2 -Wall -Wno-implicit-int -c ../../version-2_5_11/libs/FScreen.c ../../version-2_5_11/libs/FScreen.c:74: X11/extensions/xinerama.h: No such file or directory You can send any additional patches to the list. I'm not sure what to do to fix that. I suppose there may be some way to check for the header in configure, and if it's not present (Solaris 7 11/99, or Solaris 8) I could just sub in the contents. They're quite minimal. This seem to objectionable to people? I don't see any problem with Xinerama only working on only Sol 9 or later. In other words, requiring the header. Getting compile errors on a default configure on Sol 8 is no good. -- Dan Espen E-mail: [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: Solaris Xinerama support
Dan Espen wrote: Didn't you say the Sol 9/10 header would work on Sol 8. Why not make the header required. If someone wants Xinerama on Sol 8, make them supply the header. It does, but it seems like having the xinerama support enabled with no user effort for Solaris 8 users would be worth having. You don't need to be an admin, or even very smart, to build a window manager. Making sure you can put an extension somewhere and have auto-conf'd programs find them requires more of the user. It only requires putting 4 lines in FScreen.c. One #def, and three prototypes. Actually, we're only using two of the functions, so we could take out the other prototype. - Chris -- 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: Solaris Xinerama support
Chris Ross [EMAIL PROTECTED] writes: Dan Espen wrote: Didn't you say the Sol 9/10 header would work on Sol 8. Why not make the header required. If someone wants Xinerama on Sol 8, make them supply the header. It does, but it seems like having the xinerama support enabled with no user effort for Solaris 8 users would be worth having. You don't need to be an admin, or even very smart, to build a window manager. Making sure you can put an extension somewhere and have auto-conf'd programs find them requires more of the user. It only requires putting 4 lines in FScreen.c. One #def, and three prototypes. Actually, we're only using two of the functions, so we could take out the other prototype. If the #define'd stuff is only used on Solaris, when the header isn't there, and the library support is there, I'd say that was OK. -- Dan Espen E-mail: [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: Solaris Xinerama support
Chris Ross [EMAIL PROTECTED] writes: Chris Ross wrote: Okay. I don't know how many of you know this, but Solaris ships an Xsun that has Xinerama support in it (as of the last dist. of Solaris 7). *But*, in typical Sun Microsystems style, there is no Xinerama library, nor header file. Oops. I should've mentioned that this patch was tested with Solaris 8, but will only work on Solaris 8 with the X11/extensions/xinerama.h header copied from Solaris 9. Solaris' 9 and 10 ship with this header in place, so will work with no additional effort. On my Solaris 8 machine without that header, I got: With Xinerama multi-head support? yes (Using Solaris Xinerama calls) In what sense won't it work? -- Dan Espen E-mail: [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: Solaris Xinerama support
Dan Espen [EMAIL PROTECTED] writes: Chris Ross [EMAIL PROTECTED] writes: Chris Ross wrote: Okay. I don't know how many of you know this, but Solaris ships an Xsun that has Xinerama support in it (as of the last dist. of Solaris 7). *But*, in typical Sun Microsystems style, there is no Xinerama library, nor header file. Oops. I should've mentioned that this patch was tested with Solaris 8, but will only work on Solaris 8 with the X11/extensions/xinerama.h header copied from Solaris 9. Solaris' 9 and 10 ship with this header in place, so will work with no additional effort. On my Solaris 8 machine without that header, I got: With Xinerama multi-head support? yes (Using Solaris Xinerama calls) In what sense won't it work? I guess I can answer my own question, it configures but doesn't compile: gcc -DHAVE_CONFIG_H -I. -I../../version-2_5_11/libs -I.. -I../../version-2_5_11 -I/opt/public/include -I/usr/openwin/include -I/opt/public/include -g -O2 -Wall -Wno-implicit-int -c ../../version-2_5_11/libs/FScreen.c ../../version-2_5_11/libs/FScreen.c:74: X11/extensions/xinerama.h: No such file or directory You can send any additional patches to the list. -- Dan Espen E-mail: [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]
Solaris Xinerama support
Okay. I don't know how many of you know this, but Solaris ships
an Xsun that has Xinerama support in it (as of the last dist.
of Solaris 7). *But*, in typical Sun Microsystems style, there
is no Xinerama library, nor header file.
So, in doing some research, it appears there are a few functions
in libXext, that while providing a totally different API, will
allow the needed access to the Xinerama extension in the server.
So, I updated acconfig.h, configure.in, fvwm/fvwm.c (which
is an avoidable change, if you want to ignore it), and
libs/FScreen.c.
Patch for the above is attached. Should I gen diffs to
configure and config.h.in, or will those get taken care
of (either automatically, or by someone else with the blessed
autoconf installation)?
Thanks...
- Chris
Index: acconfig.h
===
RCS file: /home/cvs/fvwm/fvwm/acconfig.h,v
retrieving revision 1.72
diff -u -u -r1.72 acconfig.h
--- acconfig.h 8 Jul 2004 10:08:09 - 1.72
+++ acconfig.h 13 Aug 2004 15:31:23 -
@@ -32,6 +32,9 @@
/* Define if Xinerama library is used. */
#undef HAVE_XINERAMA
+/* Define if Solaris' Xinerama calls are being used. */
+#undef HAVE_SOLARIS_XINERAMA
+
/* Define if Xrender library is used. */
#undef HAVE_XRENDER
Index: configure.in
===
RCS file: /home/cvs/fvwm/fvwm/configure.in,v
retrieving revision 1.294
diff -u -u -r1.294 configure.in
--- configure.in23 May 2004 16:20:23 - 1.294
+++ configure.in13 Aug 2004 15:31:23 -
@@ -298,9 +298,13 @@
$UNSET ac_cv_lib_Xinerama_XineramaIsActive
AC_CHECK_LIB(Xinerama, XineramaIsActive,
with_xinerama=yes; Xinerama_LIBS=-lXinerama; AC_DEFINE(HAVE_XINERAMA),
+AC_CHECK_LIB(Xext, XineramaGetState,
+with_xinerama=yes; Xinerama_LIBS=-lXext; AC_DEFINE(HAVE_XINERAMA)
+AC_DEFINE(HAVE_SOLARIS_XINERAMA)
+problem_xinerama= (Using Solaris Xinerama calls),
with_xinerama=no; Xinerama_LIBS=
problem_xinerama=: Failed to detect libXinerama,
-[$X_LIBS $X_PRE_LIBS -lXext -lX11 $X_EXTRA_LIBS])
+[$X_LIBS $X_PRE_LIBS -lXext -lX11 $X_EXTRA_LIBS]))
fi
AC_SUBST(Xinerama_LIBS)
AC_SUBST(Xinerama_CFLAGS)
Index: fvwm/fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.368
diff -u -u -r1.368 fvwm.c
--- fvwm/fvwm.c 15 Jul 2004 13:12:28 - 1.368
+++ fvwm/fvwm.c 13 Aug 2004 15:31:23 -
@@ -1312,6 +1312,9 @@
strcat(support_str, Bidi text,);
#endif
#ifdef HAVE_XINERAMA
+# ifdef HAVE_SOLARIS_XINERAMA
+ strcat(support_str, [Solaris' odd-ball]);
+# endif
strcat(support_str, Xinerama,);
#endif
#ifdef HAVE_XRENDER
Index: libs/FScreen.c
===
RCS file: /home/cvs/fvwm/fvwm/libs/FScreen.c,v
retrieving revision 1.22
diff -u -u -r1.22 FScreen.c
--- libs/FScreen.c 17 Mar 2004 14:42:54 - 1.22
+++ libs/FScreen.c 13 Aug 2004 15:31:23 -
@@ -69,8 +69,54 @@
#include PictureBase.h
#ifdef HAVE_XINERAMA
-#define FScreenHaveXinerama 1
-#include X11/extensions/Xinerama.h
+# define FScreenHaveXinerama 1
+# ifdef HAVE_SOLARIS_XINERAMA
+# include X11/extensions/xinerama.h
+typedef struct
+{
+ int screen_number;
+ short x_org;
+ short y_org;
+ short width;
+ short height;
+} XineramaScreenInfo;
+# define XineramaIsActive(d) XineramaGetState((d),0)
+# define XineramaQueryScreens(d,b)solaris_XineramaQueryScreens((d),(b))
+# define XineramaQueryExtension(d,b,c)1 /* Lie, for now */
+static XineramaScreenInfo *
+solaris_XineramaQueryScreens(Display *d, int *xin_nscreens)
+{
+ XineramaScreenInfo *screens = NULL;
+ XRectangle monitors[MAXFRAMEBUFFERS];
+ unsigned char hints[16];
+
+ int result = XineramaGetInfo(d, DefaultScreen(d), monitors, hints,
+xin_nscreens);
+ if (result)
+ {
+ int m;
+
+ screens = (XineramaScreenInfo
*)malloc(sizeof(XineramaScreenInfo) * (*xin_nscreens));
+ for (m = 0; m *xin_nscreens; ++m)
+ {
+ screens[m].screen_number = m;
+ screens[m].x_org = monitors[m].x;
+ screens[m].y_org = monitors[m].y;
+ screens[m].width = monitors[m].width;
+ screens[m].height = monitors[m].height;
+ }
+ }
+ else
+ {
+ fprintf(stderr, Error getting Xinerama information\n);
+ *xin_nscreens = 0;
+ }
+
+ return (screens);
+}
+# else /* Must be XFree86 Xinerama */
+# include X11/extensions/Xinerama.h
+# endif
#else
#define FScreenHaveXinerama 0
typedef struct
Re: Solaris Xinerama support
Chris Ross wrote: Okay. I don't know how many of you know this, but Solaris ships an Xsun that has Xinerama support in it (as of the last dist. of Solaris 7). *But*, in typical Sun Microsystems style, there is no Xinerama library, nor header file. Oops. I should've mentioned that this patch was tested with Solaris 8, but will only work on Solaris 8 with the X11/extensions/xinerama.h header copied from Solaris 9. Solaris' 9 and 10 ship with this header in place, so will work with no additional effort. That should be noted somewhere, I'm sure. :-) - Chris -- 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]
CVS domivogt: * Fixed placement of menus on Xinerama screens.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/05/24 14:12:29 Modified files: . : ChangeLog fvwm : fvwm.1.in menus.c move_resize.c libs : FScreen.c Log message: * Fixed placement of menus on Xinerama screens. -- 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]
CVS domivogt: * Clarified that --enable-xinerama-emulation is only useful for developers.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/05/03 06:00:53 Modified files: . : configure.in Log message: * Clarified that --enable-xinerama-emulation is only useful for developers. -- 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]
CVS domivogt: * Fixed a menu placement problem w/ xinerama.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/03/08 14:04:40 Modified files: . : Tag: branch-2_4 ChangeLog NEWS docs : Tag: branch-2_4 ANNOUNCE fvwm : Tag: branch-2_4 menus.c Log message: * Fixed a menu placement problem w/ xinerama. -- 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]
CVS domivogt: * Re-added with-xinerama-emulation optioen that vanished some days ago.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/03/01 01:11:18 Modified files: . : ChangeLog configure.in utils : ChangeLog configure_dev.sh Log message: * Re-added with-xinerama-emulation optioen that vanished some days ago. * Added autolocal to configure_dev.sh. -- 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 windowlist patch
On Thu, Feb 21, 2002 at 12:20:28PM +, Darren Marshall wrote: Attached is a patch to fix a problem where clicking the mouse button to popup the windowlist on the secondary screen of an xinerama setup always pops up on the primary screen. I'll apply the patch shortly. Thanks for your help. 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]
xinerama windowlist patch
Attached is a patch to fix a problem where clicking the mouse button to popup
the windowlist on the secondary screen of an xinerama setup always pops up on
the primary screen.
This e-mail and any attachments are confidential. If you are not the intended
recipient, please notify us immediately by reply e-mail and then delete this
message from your system. Do not copy this e-mail or any attachments, use the
contents for any purpose, or disclose the contents to any other person: to do
so could be a breach of confidence.
--- windowlist.c.orig Thu Feb 21 11:59:52 2002
+++ windowlist.cThu Feb 21 12:01:31 2002
@@ -158,6 +158,11 @@
memset(mops, 0, sizeof(mops));
memset(mret, 0, sizeof(MenuReturn));
+
+ /* parse postitioning args - must call this even if no action is given
+ * because it sets the xinerama screen origin */
+ opts = get_menu_options(action, w, tmp_win, eventp, NULL, NULL, mops);
+
if (action *action)
{
/* Look for condition - CreateFlagString returns NULL if no '(' or '[' */
@@ -175,10 +180,6 @@
CreateConditionMask(cond_flags, mask);
free(cond_flags);
}
-
-/* parse postitioning args - must call this even if no action is given
- * because it sets the xinerama screen origin */
-opts = get_menu_options(action, w, tmp_win, eventp, NULL, NULL, mops);
/* parse options */
while (opts *opts)
CVS olicha: * Added the possibility to add an Xinerama screen to the 4 numerics
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 01/10/04 11:10:52 Modified files: fvwm : fvwm2.1 style.c . : ChangeLog Log message: * Added the possibility to add an Xinerama screen to the 4 numerics Iconbox format * Warning I've written some doc (fvwm2.1 lines 4846-4873) -- 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: Some Xinerama problems
On Thu, Sep 30, 2021 at 10:16:34PM +0200, Dominik Vogt wrote: On Fri, Sep 28, 2001 at 05:23:18PM +0200, Olivier Chapuis wrote: Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). I've noted a few problems with menu position and IconBox 1. if WindowList is called without argument as well as if a menu key binding of the form Key key Context Modifier Menu MyMenu _No_arg_ is activate, then the window list (or the menu) always popup on screen 0. Fixed. With just the WindowList commands without any options, the screen was not set correctly. Ok, but there are an other problem: it is possible to call the WindowList or a menu via a mouse binding function as: DestroyFunc MouseXX AddToFunc MouseXX + I Mouse $0 $2 $3 $4 $5 $6 $7 $8 $9 OR + I Mouse $1 $2 $3 $4 $5 $6 $7 $8 $9 This type of function allows to switch between mouse 2 and 3 in a config file where mouse bindings are defined by MouseXX 2 3 R A WindowList MouseXX 2 3 R S WindowList (CurrentDesk) ..etc. We use this in fvwm-themes. So then the action which arrive to get_menu_options (menu.c) is '' and then the menu position is not good. Ok this is strange but this work with Xinerama Off, the get_option_options has a test for this case (if (!tok)) and strictly speaking an menu position should be equivalent to a null one. I've commited a safe and obvious fix to get_option_options. 3. It seems natural for me that iconification happen on the current screen, so I test IconBox with Style * IconBox [EMAIL PROTECTED], IconGrid 64 10, IconFill left bottom In normal use this work fine. However, if the above command is entered in a way or an other when the mouse cursor is on screen 1 the icons on screen 0 go in a random location (in the top of screen 0). You are misinterpreting what your style line does: it creates an icon box with the given dimensions on whatever screen the pointer is on at the time the style command is issued. It *does not* create one icon box on each screen: this must be done manually. What fvwm does is this: - Create a default icon box that covers the primary screen. (screen 0). - Create the given icon box on the screen with the pointer. (screen 1). Whenever a window is iconified, fvwm looks for a suitable icon box in this order: - Icon boxes that intersect with the screen of the window. - Any icon box other than the default icon box on any screen. - The default icon box. So, what you are seeing is icons being placed in the default icon box on the primary screen since this is the only box that intersects the primary screen. You have to specify a separate icon box for each screen. Of course it would be nice to have a way to specify the same icon box for each screen in a single style command, but I don't see how this can be done easily (most of the icon box calculations are still in style.c). Ok I think I understand. But: a. The order you mention is not totally exact. For example if I've: Style * Iconbox [EMAIL PROTECTED], IconFill left top (Primary is screen 0) then if I iconify a window which is in screen 1 the icon go on the bottom right of screen 0 (no iconbox if found I think). This is caused by the lines in AutoPlaceIcon (icons.c): if (FScreenIsRectangleOnScreen(fscr, FSCREEN_XYPOS, ref)) loc_ok = True; else loc_ok_wrong_screen = True; The test is alawys false as there are no iconbox on screen 1 (and this test may be always false if you iconify from an other page that the page of the window). Moreover if I have: Style * Iconbox [EMAIL PROTECTED],IconFill left top,\ Iconbox [EMAIL PROTECTED], IconFill bottom left Then if the screen 1 iconbox is full, and I iconify a window on screen 1, no iconbox will be found. I think that the order is: go throught all the iconboxes (as there are entred + the default iconbox) take the iconbox only if it is on the same screen than the window. b. IMHO, the @c logic is wrong: a command like Style * Iconbox [EMAIL PROTECTED],IconFill left top will move the icons in an inacceptable way (especially if we fix the bug of a) and so is usable only at startup or if no windows are iconified. Ok, Ok, ... I should use multiple iconboxes and do not use @c. But what I am trying to do is to found a good iconbox for any Xinerama settings (optionally Off). As @c is unusable I suggest to change the @c logic: here current may means the center of the window and not the location of the pointer. I do not think that it is a difficult change. The idea is simple: replace /* get the screen dimensions for the icon box */ FScreenGetScrRect(NULL, icon_boxes_ptr-IconScreen, ref.x, ref.y
CVS olicha: * fixed Xinerama placement of menu with empty but not null position hints
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 01/10/02 06:18:41 Modified files: . : ChangeLog fvwm : menus.c Log message: * fixed Xinerama placement of menu with empty but not null position hints -- 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]
CVS domivogt: * Icon placement fixes w/ Xinerama.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/10/02 09:03:47 Modified files: . : ChangeLog NEWS fvwm : borders.c fvwm2.1 icons.c menus.c libs : FScreen.c FScreen.h defaults.h Log message: * Icon placement fixes w/ Xinerama. * New screen specifier 'w' for IconBox command. -- 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: Some Xinerama problems
On Fri, Sep 28, 2001 at 05:23:18PM +0200, Olivier Chapuis wrote: Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). I've noted a few problems with menu position and IconBox 1. if WindowList is called without argument as well as if a menu key binding of the form Key key Context Modifier Menu MyMenu _No_arg_ is activate, then the window list (or the menu) always popup on screen 0. Fixed. With just the WindowList commands without any options, the screen was not set correctly. 2. For testing let say we have the following binding: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (the @c is not really important). So when I activate this bindings the menu popup at [EMAIL PROTECTED] but if I am on screen 0 and I popup submenus (and subsubmenus) then the menu go into screen 1 (so it is exactly as if I've no XineramaSls support). This does not happen on screen 1 (but here the left limit is my monitor). Similarly if I use: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (and MenuFvwmRoot is larger than 10p) the menu appear in between screen 0 and 1 as it should appear on screen 0 (as it will do with [EMAIL PROTECTED] on screen 1). Fixed. Originally, rectangles referred always to the global screen. Now, the screen part of the geometry also confines the menu into that screen (defaulting to the primary screen). 3. It seems natural for me that iconification happen on the current screen, so I test IconBox with Style * IconBox [EMAIL PROTECTED], IconGrid 64 10, IconFill left bottom In normal use this work fine. However, if the above command is entered in a way or an other when the mouse cursor is on screen 1 the icons on screen 0 go in a random location (in the top of screen 0). You are misinterpreting what your style line does: it creates an icon box with the given dimensions on whatever screen the pointer is on at the time the style command is issued. It *does not* create one icon box on each screen: this must be done manually. What fvwm does is this: - Create a default icon box that covers the primary screen. (screen 0). - Create the given icon box on the screen with the pointer. (screen 1). Whenever a window is iconified, fvwm looks for a suitable icon box in this order: - Icon boxes that intersect with the screen of the window. - Any icon box other than the default icon box on any screen. - The default icon box. So, what you are seeing is icons being placed in the default icon box on the primary screen since this is the only box that intersects the primary screen. You have to specify a separate icon box for each screen. Of course it would be nice to have a way to specify the same icon box for each screen in a single style command, but I don't see how this can be done easily (most of the icon box calculations are still in style.c). Similar things happen with All (CurrentScreen Iconic) RecaptureWindow Also if I have a window which is almost all in screen 1 and if I Iconify it with a title button on screen 0, then the icon go in a random location. More important, if I have a window on screen 1 and if I Iconify it with IconMan which is on screen 0, then again the icon go in a bad location (in screen 0). In the above, screen 0 and 1 are interchangeable. I've not investigate problem 2. 3. I may take a look if no other (more competent than me for these) have the time to fix it (before 2.4.3?). 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]
CVS domivogt: * Xinerama fixes for bugs reported by Olivier in menu code, WindowList.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/10/01 16:07:03 Modified files: . : ChangeLog NEWS fvwm : add_window.c builtins.c events.c fvwm2.1 icons.c menus.c move_resize.c placement.c stack.c update.c windowlist.c libs : FScreen.c FScreen.h Log message: * Xinerama fixes for bugs reported by Olivier in menu code, WindowList. * Applied Xinerama patches by Sidik (partially rewritten). * Removed useless code pointed out by Suzanne Britton. * Fixed flickering icon titles. -- 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: Some Xinerama problems
On Fri, 28 Sep 2001, Olivier Chapuis wrote: Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). Most modern laptops are dual-headed: first head is laptop's flat panel, the second is VGA output. While VGA typically duplicates the panel, at least those with ATI cards (e.g. Compaq Presario 1700 with ATI Rage Mobility M2) and with Permedia ones are able of displaying different pictures on these heads, and even with different resolutions. _ 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]
Some Xinerama problems
Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). I've noted a few problems with menu position and IconBox 1. if WindowList is called without argument as well as if a menu key binding of the form Key key Context Modifier Menu MyMenu _No_arg_ is activate, then the window list (or the menu) always popup on screen 0. These problems has been already remarked on this list. I've a very simple fix for this bug, but maybe, Dominik, you prefer to fix it. 2. For testing let say we have the following binding: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (the @c is not really important). So when I activate this bindings the menu popup at [EMAIL PROTECTED] but if I am on screen 0 and I popup submenus (and subsubmenus) then the menu go into screen 1 (so it is exactly as if I've no XineramaSls support). This does not happen on screen 1 (but here the left limit is my monitor). Similarly if I use: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (and MenuFvwmRoot is larger than 10p) the menu appear in between screen 0 and 1 as it should appear on screen 0 (as it will do with [EMAIL PROTECTED] on screen 1). 3. It seems natural for me that iconification happen on the current screen, so I test IconBox with Style * IconBox [EMAIL PROTECTED], IconGrid 64 10, IconFill left bottom In normal use this work fine. However, if the above command is entered in a way or an other when the mouse cursor is on screen 1 the icons on screen 0 go in a random location (in the top of screen 0). Similar things happen with All (CurrentScreen Iconic) RecaptureWindow Also if I have a window which is almost all in screen 1 and if I Iconify it with a title button on screen 0, then the icon go in a random location. More important, if I have a window on screen 1 and if I Iconify it with IconMan which is on screen 0, then again the icon go in a bad location (in screen 0). In the above, screen 0 and 1 are interchangeable. I've not investigate problem 2. 3. I may take a look if no other (more competent than me for these) have the time to fix it (before 2.4.3?). 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]
SGI Xinerama API
Hi, I'm preparing an SGI package of fvwm and I have a couple issues with your implementation of Xinerama. SGI is currently developing the Xinerama library as per the latest spec (Actually SGI is even beyond the spec for certain things) It sounds like you're using an old spec. A couple differences : Bool XineramaActive() replaces char XineramaIsActive() XineramaScreenInfo *XineramaQueryScreens(disp, count) along with the typedef struct are not in the spec anymore. An equivalent could be found by using XineramaGetScreenCount and XineramaGetScreenSize, but the very latest spec will show up a new function, XineramaGetData so... a couple questions: - how do we keep up on API spec changes (very often yet) - is anybody following this very close ? - I'll patch 2.4.2 for SGI use. Want the spec ? Thanks! Stephane -- SILICON GRAPHICS EUROPEAN MANUFACTURING CENTER ## Stephane Rosa Tel : +41 (0)32 843-3638 Business Analyst Fax : +41 (0)32 843-3909 APS/FP Project GSM : +41 (0)79 616-0828 -- ircnoc.neu.sgi.com SGI Intranet IRC : EuroOper on #irchelp irc.stealth.net Euro-IRCNet IRC : Clipper on #radionet -- 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: SGI Xinerama API
On Wed, 26 Sep 2001, Stephane Rosa wrote: Hi, I'm preparing an SGI package of fvwm and I have a couple issues with your implementation of Xinerama. SGI is currently developing the Xinerama library as per the latest spec (Actually SGI is even beyond the spec for certain things) It sounds like you're using an old spec. A couple differences : Bool XineramaActive() replaces char XineramaIsActive() XineramaScreenInfo *XineramaQueryScreens(disp, count) along with the typedef struct are not in the spec anymore. An equivalent could be found by using XineramaGetScreenCount and XineramaGetScreenSize, but the very latest spec will show up a new function, XineramaGetData so... a couple questions: - how do we keep up on API spec changes (very often yet) All the Xinerama-API-related functionality is in libs/FScreen.c::FScreenInit(), and what it really needs is a) a function to check if Xinerama is present at all, b) a way to get a list of screen rectangles (viewports to global screen). Since all APIs (except old PanoramixNNN one) supply these, it is a matter of simple configure script logic plus a few #ifdef's in FScreen.c (like #if defined(XINERAMA_API_XFREE86) ... #elif defined(XINERAMA_API_XORG) ... #endif - is anybody following this very close ? I'm the person who tries to track Xinerama API flavors. - I'll patch 2.4.2 for SGI use. Want the spec ? Yes, the spec is very welcome. BTW, which spec is it? There are at least four APIs: 1) old PanoramixNNN; 2) XFree86's XineramaNNN (which is the only API currently in use by WMs and toolkits); 3) Xinerama project API (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xinerama/xinerama/xc/doc/XineramaApi.txt?rev=1.2content-type=text/vnd.viewcvs-markup); 4) X.org Xinerama task force product (which isn't published). Probably #3 and #4 are related, but I'm not sure. _ 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: SGI Xinerama API
Very interesting link, I wasn't aware of the xinerama sourceforge project. To add to your speculation regarding the relations between the xinerama apis: Since the sourceforge project leader and the x org xinerama task force chair are the same person and Mark V of xfree86 is also a sourceforge project member, I guess there is hope for 2), 3) and 4) to converge. 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: FVWM2 Xinerama patches
On Sun, 23 Sep 2001, Sidik Isani wrote: Hello - I have a suggestion for Xinerama, but I don't know enough about automake to provide a patch: we could use configure options telling fvwm2 where to look for the library and include files. Also related to Xinerama, here are better versions of some patches I posted before (now everything properly goes through the FScreen layer to calculate Xinerama screen coordinates.) We're upgrading from isolated multi-head displays to Xinerama, and with the following patches, we were able to keep the same geometry resources we use on separate DISPLAY's (:0.0, :0.1, :0.2, :0.N) and translate them to '*wmscreen: N' resources. FVWM2 looks very stable so far on our Linux/Solaris/HP-UX mix. Thanks a lot to all who worked on this. XINERAMA PATCH 1: Adds a new function to FScreen to convert global coords. XINERAMA PATCH 2: Adds a check for a *wmscreen resource. XINERAMA PATCH 3: Uses function in PATCH 1 to make USPosition windows obey StartsOnScreen Style/*wmscreen resource. XINERAMA PATCH 4: Uses PATCH 1 to cause window positions displayed while moving a window to be screen-relative whenever possible. I might not be good to put any of this in the 2.4.3 release, but I hope it is useful to someone. #4 probably needs a config file option associated with it to turn it on/off. Adding @N to the string it displays would make it nicer too. Please let me know if there's anything else needed to make these patches generally useful. Just two notes. First, isn't FScreenGetScreenXY() just a FScreenGetScrRect(arg, FSCREEN_XYPOS, dst_x, dst_y, NULL, NULL) (well, a separate call may be more handy, but Dominik has removed most of FScreenGetZZZScrRect() in favour of FScreenGetScrRect, an that looks reasonable)? Second, regarding translation of program-supplied geometry to non-global screen: what will happen to those programs which save their windows' geometries on exit and use them on restart? Wouldn't the following happen: app is started on current screen +---+---+---+ 1024*3 | 0 | 1 | 2 | +---+---+---+ (which is #1, +1024+0), it saves window position (e.g. +1030+10), and on next run (current screen is still #1) supplies it to fvwm, which translates to +(1030+1024)+10, so that the window effectively goes to screen #2? Patch #3 doesn't include %'ing the coords, which was present in previous version (yet not sure if that did the right thing). Of course, a good program should specify PPosition in this case, not USPosition, but a) I haven't tested what such apps supply (and those (mainly commercial or binary-only) progs are known to be bogus in many aspects); b) do patch #3 belongs to PPosition branch only? Hope this is a false alarm, but I think it is worth mentioning. (An obvious question is why specifying StartsOnScreen for such programs?, but this feature is so handy that there's a desire to use Style * StartsOnScreen c). _ 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: FVWM2 Xinerama patches
Hello Dmitry - Thanks for taking a look at the patches. Comments on your comments are below . . . Dmitry Yu. Bolkhovityanov wrote: | |On Sun, 23 Sep 2001, Sidik Isani wrote: | | Hello - | | I have a suggestion for Xinerama, but I don't know enough about | automake to provide a patch: we could use configure options | telling fvwm2 where to look for the library and include files. | | Also related to Xinerama, here are better versions of some patches | I posted before (now everything properly goes through the FScreen | layer to calculate Xinerama screen coordinates.) We're upgrading | from isolated multi-head displays to Xinerama, and with the following | patches, we were able to keep the same geometry resources we use on | separate DISPLAY's (:0.0, :0.1, :0.2, :0.N) and translate them to | '*wmscreen: N' resources. FVWM2 looks very stable so far on our | Linux/Solaris/HP-UX mix. Thanks a lot to all who worked on this. | | XINERAMA PATCH 1: Adds a new function to FScreen to convert global coords. | XINERAMA PATCH 2: Adds a check for a *wmscreen resource. | XINERAMA PATCH 3: Uses function in PATCH 1 to make USPosition windows | obey StartsOnScreen Style/*wmscreen resource. | XINERAMA PATCH 4: Uses PATCH 1 to cause window positions displayed while | moving a window to be screen-relative whenever possible. | | I might not be good to put any of this in the 2.4.3 release, but | I hope it is useful to someone. #4 probably needs a config file | option associated with it to turn it on/off. Adding @N to the | string it displays would make it nicer too. | | Please let me know if there's anything else needed to make these | patches generally useful. | | Just two notes. | | First, isn't FScreenGetScreenXY() just a | |FScreenGetScrRect(arg, FSCREEN_XYPOS, dst_x, dst_y, NULL, NULL) | |(well, a separate call may be more handy, but Dominik has removed most of |FScreenGetZZZScrRect() in favour of FScreenGetScrRect, an that looks |reasonable)? OK, I see now how it could be used to convert between coordinate systems. We'd still have to subtract (dst_x,dst_y) from the original coordinate, since GetScrRect returns the rectangle, not transformed coordinates. And we don't have a way to get the screen number. I guess another parameter could be added to GetScrRect, int *screen, if you don't like the separate function for a coordinate transform? | Second, regarding translation of program-supplied geometry to |non-global screen: what will happen to those programs which save their |windows' geometries on exit and use them on restart? Wouldn't the They should work correctly. My first patch, with %'ing (which would have broken on unequal screen sizes) is no longer needed either. Here's why: Let's say an application is started with Xresource: foo.wmscreen: 1 Command: foo -geometry +6+10 and we're using your example screen layout: |+---+---+---+ 1024*3 || 0 | 1 | 2 | |+---+---+---+ The application doesn't even look at wmscreen, but it requests a position of +6+10 on the global screen. GetScreenXY figures out that this pixel falls on screen 0 and returns screen-relative coordinates of +6+10. This is added to screen_g.x,y, the origin of screen 1 (because of the *wmscreen: 1) resulting in global +1030+10. The window pops up on screen 1 (no matter what the current screen is.) If the application saves this as its position, let's see what happens: GetScreenXY sees +1030+10, but figures out that this pixel falls on screen 1 this time, and in screen-relative coordinates this is +6+10. It returns 1 (which we ignore right now) and the coordinates +6+10. This is again added to screen_g.x,y for the same global +1030+10. Same logic works for StartsOnScreen c, and also for foo -xrm '*wmscreen: 1' -geometry +6+10 with _no_ StartsOnScreen style or global Xresource. In this last case, the application saves its position as +1030+10, and since StartsOnScreen +1030+10 is interpreted relative to the global screen. As far as I can tell (and have tested), all cases work properly. Ok, well there is one small obscure feature: - If you specify negative geometry instead of positive (i.e., to place a window some distance from the bottom and/or right screen edge) AND - If a StartsOnScreen Style is in effect for the window AND - The selected screen is a different size from the farthest screen then the window will pop up relative to the bottom/right of the screen you selected, but as if the selected screen was the size of the last screen. Basically, if someone has all three of these conditions, then use positive geometries! (And the application will never save its own geometry as negative, so that works too, since positive coordinates are not susceptible to this.) |[...] | Of course, a good program should specify PPosition
FVWM2 Xinerama patches
Hello - I have a suggestion for Xinerama, but I don't know enough about automake to provide a patch: we could use configure options telling fvwm2 where to look for the library and include files. Also related to Xinerama, here are better versions of some patches I posted before (now everything properly goes through the FScreen layer to calculate Xinerama screen coordinates.) We're upgrading from isolated multi-head displays to Xinerama, and with the following patches, we were able to keep the same geometry resources we use on separate DISPLAY's (:0.0, :0.1, :0.2, :0.N) and translate them to '*wmscreen: N' resources. FVWM2 looks very stable so far on our Linux/Solaris/HP-UX mix. Thanks a lot to all who worked on this. XINERAMA PATCH 1: Adds a new function to FScreen to convert global coords. XINERAMA PATCH 2: Adds a check for a *wmscreen resource. XINERAMA PATCH 3: Uses function in PATCH 1 to make USPosition windows obey StartsOnScreen Style/*wmscreen resource. XINERAMA PATCH 4: Uses PATCH 1 to cause window positions displayed while moving a window to be screen-relative whenever possible. I might not be good to put any of this in the 2.4.3 release, but I hope it is useful to someone. #4 probably needs a config file option associated with it to turn it on/off. Adding @N to the string it displays would make it nicer too. Please let me know if there's anything else needed to make these patches generally useful. Be seeing you, - Sidik -- 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]
FVWM2 Xinerama patch 1
diff -ru fvwm-snap-20010916/libs/FScreen.c fvwm-2.5.0-cfht/libs/FScreen.c
--- fvwm-snap-20010916/libs/FScreen.c Sat Sep 15 01:00:05 2001
+++ fvwm-2.5.0-cfht/libs/FScreen.c Tue Sep 18 20:41:10 2001
@@ -528,6 +528,27 @@
return 0;
}
+/* Returns the screen of which (global_x, global_y) is a pixel, and
+ * returns the screen-relative (x,y) if x and y are not NULL.
+ */
+int FScreenGetScreenXY(
+ int global_x, int global_y, int *x, int *y)
+{
+ int screen = FindScreenOfXY(global_x, global_y);
+
+ if (screen == 0)
+ {
+if (x) *x = global_x;
+if (y) *y = global_y;
+ }
+ else if (screen 0)
+ {
+if (x) *x = global_x - screens[screen].x_org;
+if (y) *y = global_y - screens[screen].y_org;
+ }
+ return screen;
+}
+
/* Returns the specified screens geometry rectangle. screen can be a screen
* number or any of the values FSCREEN_GLOBAL, FSCREEN_CURRENT,
* FSCREEN_PRIMARY or FSCREEN_XYPOS. The arg union only has a meaning for
diff -ru fvwm-snap-20010916/libs/FScreen.h fvwm-2.5.0-cfht/libs/FScreen.h
--- fvwm-snap-20010916/libs/FScreen.h Fri Sep 14 01:00:08 2001
+++ fvwm-2.5.0-cfht/libs/FScreen.h Tue Sep 18 20:20:24 2001
@@ -44,6 +44,8 @@
void FScreenSetPrimaryScreen(int scr);
/* Screen info */
+int FScreenGetScreenXY(
+ int global_x, int global_y, int *x, int *y);
Bool FScreenGetScrRect(
fscreen_scr_arg *arg, int screen, int *x, int *y, int *w, int *h);
void FScreenGetResistanceRect(
--
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]
FVWM2 Xinerama patch 2
diff -ru fvwm-snap-20010916/fvwm/fvwm2.1 fvwm-2.5.0-cfht/fvwm/fvwm2.1
--- fvwm-snap-20010916/fvwm/fvwm2.1 Sun Sep 16 01:00:02 2001
+++ fvwm-2.5.0-cfht/fvwm/fvwm2.1Sat Sep 15 16:54:45 2001
@@ -5239,7 +5239,7 @@
.IR StartsOnDesk .
For those standard Xt programs which understand this usage, the
starting desk/page can also be specified via a resource (e.g.,
--xrm 'Fvwm.Page: 1 0 2').
+-xrm '*page: 1 0 2').
.I StartsOnPage
in conjunction with
.I SkipMapping
@@ -5254,19 +5254,23 @@
A new window is placed on the specified Xinerama screen. The
default is to place windows on the screen that contains the mouse
pointer at the time the window is created.
-
-.I StartsOnPage
-functions exactly like
-.IR StartsOnDesk .
+However, those windows which are not placed by FVWM (i.e., those with
+a USPosition hint from a user specified geometry) are normally placed
+in a position relative to the global screen. The
+.I StartsOnScreen
+style is also useful to cause these windows to be placed relative
+to a specific Xinerama screen. For example:
+.EX
+Style * StartsOnScreen c
+.EE
+Would cause all windows, including those with their own geometry
+to be placed relative to the current Xinerama screen rather than
+the global screen.
For those standard Xt programs which understand this usage, the
starting desk/page can also be specified via a resource (e.g.,
--xrm 'Fvwm.Page: 1 0 2').
-.I StartsOnPage
-in conjunction with
-.I SkipMapping
-is a useful technique when you want to start an app on some other
-page and continue with what you were doing, rather than waiting
-for it to appear.
+-xrm '*wmscreen: c'). ('wmscreen' was chosen
+because some applications already use '.screen' for other
+purposes.)
.I StartsOnPageIncludesTransients
causes the
diff -ru fvwm-snap-20010916/fvwm/add_window.c fvwm-2.5.0-cfht/fvwm/add_window.c
--- fvwm-snap-20010916/fvwm/add_window.cSun Sep 16 01:00:02 2001
+++ fvwm-2.5.0-cfht/fvwm/add_window.c Sat Sep 15 20:38:13 2001
@@ -56,6 +56,7 @@
#include stdio.h
#include libs/fvwmlib.h
+#include libs/FScreen.h
#include fvwm.h
#include externs.h
#include cursor.h
@@ -587,6 +588,12 @@
SSET_START_DESK(*pstyle, SGET_START_DESK(*pstyle) + 1);
}
pstyle-flags.use_start_on_desk = 1;
+}
+if (GetResourceString(db, wmscreen, client_argv[0], rm_value)
+ rm_value.size != 0)
+{
+ SSET_START_SCREEN(*pstyle, FScreenGetScreenArgument(rm_value.addr, 'c'));
+ pstyle-flags.use_start_on_screen = 1;
}
if (GetResourceString(db, page, client_argv[0], rm_value)
rm_value.size != 0)
--
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]
FVWM2 Xinerama patch 3
diff -ru fvwm-snap-20010916/fvwm/placement.c fvwm-2.5.0-cfht/fvwm/placement.c
--- fvwm-snap-20010916/fvwm/placement.c Fri Sep 7 04:37:27 2001
+++ fvwm-2.5.0-cfht/fvwm/placement.cTue Sep 18 20:27:14 2001
@@ -922,6 +922,31 @@
/* the USPosition was specified, or the window is a transient,
* or it starts iconic so place it automatically */
+if (SUSE_START_ON_SCREEN(sflags) flags.do_honor_starts_on_screen)
+{
+ int global_x = tmp_win-attr.x;
+ int global_y = tmp_win-attr.y;
+
+ /*
+ * If StartsOnScreen has been given for a window, translate its
+ * USPosition so that it is relative to that particular screen.
+ * If we don't do this, then a geometry would completely cancel
+ * the effect of the StartsOnScreen style.
+ *
+ * So there are two ways to get a window to pop up on a particular
+ * Xinerama screen. 1: The intuitive way giving a geometry hint
+ * relative to the desired screen's 0,0 along with the appropriate
+ * StartsOnScreen style (or *wmscreen resource), or 2: Do NOT
+ * specify a Xinerama screen (or specify it to be 'g') and give
+ * the geometry hint in terms of the global screen.
+ */
+ FScreenGetScreenXY(global_x, global_y,
+tmp_win-attr.x, tmp_win-attr.y);
+
+ tmp_win-attr.x += screen_g.x; /* Back to global coordinates, but */
+ tmp_win-attr.y += screen_g.y; /* forced to the right screen now. */
+}
+
/*
* If SkipMapping, and other legalities are observed, adjust for
* StartsOnPage.
--
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]
FVWM2 Xinerama patch 4
diff -ru fvwm-snap-20010916/fvwm/move_resize.c
fvwm-2.5.0-cfht/fvwm/move_resize.c
--- fvwm-snap-20010916/fvwm/move_resize.c Fri Sep 7 04:37:27 2001
+++ fvwm-2.5.0-cfht/fvwm/move_resize.c Tue Sep 18 20:27:18 2001
@@ -457,11 +457,17 @@
{
char str [100];
int offset;
+ int screen_x, screen_y;
+ /*
+ * Translate x,y into local screen coordinates, in case Xinerama is used.
+ */
+ FScreenGetScreenXY(x, y, screen_x, screen_y);
+
if (Scr.gs.do_hide_position_window)
return;
position_geometry_window(eventp);
- (void) sprintf (str, GEOMETRY_WINDOW_POS_STRING, x, y);
+ (void) sprintf (str, GEOMETRY_WINDOW_POS_STRING, screen_x, screen_y);
if (Init)
{
XClearWindow(dpy, Scr.SizeWindow);
--
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]
Some quirky things with xinerama.
I'm using a stock redhat7.1 system, except I've upgraded to XFree 4.1.0 and have two monitor's with xinerama support working happily. But!... and this may actually be a fvwm-themes-devel question... With Screen1 LeftOf Screen0 |-| |--| | | | | | Screen1| | Screen0 | | | | | | | | | |-| |--| I'm finding strange quirky things like WindowList and other menus popping up on either screen. For instance I'm using latest fvwm cvs as well as fvwm-themes cvs, and choose CDE themes half of the cde button bar module appears halfway off the screen of Screen0 which is on the right like the #'s in the above diagram. And if you manually drag it into view say to Screen1 which I have on the left, then clicking on any menu on the cde button bar the menu pops up on Screen0 which is on the right!? So, is that my fault for trying to do things back to front? Alex -- 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: Some quirky things with xinerama.
On Thu, Sep 20, 2001 at 08:56:41PM +0930, Alex Wallis wrote: I'm using a stock redhat7.1 system, except I've upgraded to XFree 4.1.0 and have two monitor's with xinerama support working happily. But!... and this may actually be a fvwm-themes-devel question... With Screen1 LeftOf Screen0 |-| |--| | | | | | Screen1| | Screen0 | | | | | | | | | |-| |--| I'm finding strange quirky things like WindowList and other menus popping up on either screen. For instance I'm using latest fvwm cvs as well as fvwm-themes cvs, and choose CDE themes half of the cde button bar module appears halfway off the screen of Screen0 which is on the right like the #'s in the above diagram. And if you manually drag it into view say to Screen1 which I have on the left, then clicking on any menu on the cde button bar the menu pops up on Screen0 which is on the right!? So, is that my fault for trying to do things back to front? Since screen 1 is bigger in the picture, I guess that it it the screen your work on primarily. It looks as if the button bar would fit nicely on screen 1. Try using XineramaPrimaryScreen 1 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: Some quirky things with xinerama.
On Thu, Sep 20, 2001 at 08:56:41PM +0930, Alex Wallis wrote: I'm using a stock redhat7.1 system, except I've upgraded to XFree 4.1.0 and have two monitor's with xinerama support working happily. But!... and this may actually be a fvwm-themes-devel question... With Screen1 LeftOf Screen0 |-| |--| | | | | | Screen1| | Screen0 | | | | | | | | | |-| |--| I'm finding strange quirky things like WindowList and other menus popping up on either screen. For instance I'm using latest fvwm cvs as well as fvwm-themes cvs, and choose CDE themes half of the cde button bar module appears halfway off the screen of Screen0 which is on the right like the #'s in the above diagram. And if you manually drag it into view say to Screen1 which I have on the left, then clicking on any menu on the cde button bar the menu pops up on Screen0 which is on the right!? So, is that my fault for trying to do things back to front? fvwm-themes is not Xinerama compliant. This will be on the TODO list. Adding a line of the form: PipeRead 'echo *FvwmButtons-Panel: Geometry 860x77+`expr ( $[vp.width] - 860 ) / 2`[EMAIL PROTECTED]' ^^ to your modules-extra should fix the cde buttons geometry. BTW, maybe it will be good to have some Xinerama support in COMMAND EXPANSION (e.g., new variables) and FvwmM4. About the menus popup by the cde button the problems come from cfg lines of the form: *FvwmButtons-Panel: (3x2+33+0, Frame 1, Icon module/large/panel-arrow.xpm, \ Padding 1 1, Colorset 11, \ Action 'Menu MenuFvwmSystem rectangle $widthx$height+$left+$top o+50 -100m') *Maybe* this is a FvwmButtons/fvwm2/Xinerama bugs or miss feature. I do not know. 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: Some quirky things with xinerama.
Dominik Vogt wrote: On Thu, Sep 20, 2001 at 08:56:41PM +0930, Alex Wallis wrote: I'm using a stock redhat7.1 system, except I've upgraded to XFree 4.1.0 and have two monitor's with xinerama support working happily. But!... and this may actually be a fvwm-themes-devel question... With Screen1 LeftOf Screen0 |-| |--| | | | | | Screen1| | Screen0 | | | | | | | | | |-| |--| I'm finding strange quirky things like WindowList and other menus popping up on either screen. For instance I'm using latest fvwm cvs as well as fvwm-themes cvs, and choose CDE themes half of the cde button bar module appears halfway off the screen of Screen0 which is on the right like the #'s in the above diagram. And if you manually drag it into view say to Screen1 which I have on the left, then clicking on any menu on the cde button bar the menu pops up on Screen0 which is on the right!? So, is that my fault for trying to do things back to front? Since screen 1 is bigger in the picture, I guess that it it the screen your work on primarily. It looks as if the button bar would fit nicely on screen 1. Try using Oh, I just can't draw. Both monitors are at the same size and same res of 1024x768 at 16 bpp, but the left is a 16M savage4 card and the right has a 4M ATI card. The left monitor should also be capable of 1600 x 1200, but I haven't figured out how to get it to work with different sizes. XineramaPrimaryScreen 1 That fixes the menus on the cde button bar module, but the built-in WindowList(right click) or windowops menus appear on the left when right-clicking on the right desktop on Screen0? Many thanks again. :) Alex -- 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]
CVS domivogt: * Removed remaining todo items to todo-3.0 and deleted todo-xinerama.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/16 07:19:42 Modified files: . : todo-3.0 Removed files: . : todo-xinerama Log message: * Removed remaining todo items to todo-3.0 and deleted todo-xinerama. -- 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]
FYI: Official Xinerama API spec
Hi! As was mentioned some time ago, Xinerama API implementation in XFree86 isn't an official X.org standard. And X environments other than XFree86 use different (and incomplete, and undisclosed) Panoramix API. A draft of upcoming standard API is available at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xinerama/xinerama/xc/doc/XineramaApi.txt?rev=1.2content-type=text/vnd.viewcvs-markup Differences from XFree86's implementation are very subtle and can be easily handled within FScreen.c with a little assistance from configure script. Additionally, Mark Vojkovich states at http://www.xfree86.org/pipermail/xpert/2001-September/011340.html that XFree86 will support both when the X.Org protocol is finalized. BTW, I'm going to contact him regarding our findings (like a desire to have a Pointer changed physical screen event). Are there any other similar things which will require assistance from X server and API? _ 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: Xinerama support for IconBox style?
On Mon, Aug 20, 2001 at 08:05:14PM -0400, Dan Espen wrote: Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] writes: On Mon, 20 Aug 2001, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. I don't think we'd want to apply the same screen test unless the user indicated that the iconbox was for a specific screen. Right now, theres no way to do that. Would it be possible to remember the screen# together with translated geometry? It can be saved, but what for? For recalculation of the icon boxes when the Xinerama command is used. Let's assume Xinerama is enabled with two screens. Style * IconBox [EMAIL PROTECTED] puts the icon box at 0 0 of screen 1. Now, Xinerama off is issued. The @1 must now refer to the global screen since there are no more Xinerama 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 support for IconBox style?
Dominik Vogt [EMAIL PROTECTED] writes: On Mon, Aug 20, 2001 at 08:05:14PM -0400, Dan Espen wrote: Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] writes: On Mon, 20 Aug 2001, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. I don't think we'd want to apply the same screen test unless the user indicated that the iconbox was for a specific screen. Right now, theres no way to do that. Would it be possible to remember the screen# together with translated geometry? It can be saved, but what for? For recalculation of the icon boxes when the Xinerama command is used. Let's assume Xinerama is enabled with two screens. Thanks, now I understand. I added the screen spec to the iconbox structure for the case when a geometry style spec is used, but the IconBox can also be defined in l r t b format. There are times when that format is required. I don't know what format you'd like to use in that case. I suppose just another string and pass it over to XineramaSupportParseScreenBit? Like: Style * Iconbox -80 240 -1 -1 g I didn't do anything but put the value in the structure. -- 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: One more Xinerama patch for FvwmWharf
On Sat, Aug 18, 2001 at 08:28:54PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! This patch deals with withdrawing Wharf to corners and with in which direction panels should open. Appliet. BTW, could you please include ChangeLog entries with your patches? BTW, there's a strange error in drawing the panel's host button. When a vertical Wharf is at the right border (and a panel slides to the left), after a panel completely appears, the host button is in two halves: the right half is pressed, while the left one is depressed. Can you post a config to demonstrate this? Presence of this effect depends on X server, but I can 100% reproduce it in Xnest ran on Matrox G450 under XFree86 4.0.3 (RH7.1, AnotherLevel). Interestingly, on the host server itself the effect seems to be 100% unreproducible. I can post a screenshot of this effect if required. You're using XNest? Usually I don't debug problems with XNest which seems to have a lot of bugs. Did you ever see this with a real X server? BTW2: wouldn't it be wise to add an item 15.5.5.5 to todo-3.0, stating Remove FvwmWharf (It's an FvwmButtons with trivial enhancements)? I'va added it to the list. 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: One more Xinerama patch for FvwmWharf
On Thu, 23 Aug 2001, Dominik Vogt wrote: On Sat, Aug 18, 2001 at 08:28:54PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! This patch deals with withdrawing Wharf to corners and with in which direction panels should open. Appliet. BTW, could you please include ChangeLog entries with your patches? Ok. For this one it is Make FvwmWharf use current Xinerama screen for choosing in which direction to slide panels and for withdrawn position calculation (khm, a bit too long, shame on me...). BTW, there's a strange error in drawing the panel's host button. When a vertical Wharf is at the right border (and a panel slides to the left), after a panel completely appears, the host button is in two halves: the right half is pressed, while the left one is depressed. Can you post a config to demonstrate this? Well, that's just AnotherLevel. I append all *FvwmWharf lines in m4-preprocessed form at the end of this mail (long lines are marked with \s). Presence of this effect depends on X server, but I can 100% reproduce it in Xnest ran on Matrox G450 under XFree86 4.0.3 (RH7.1, AnotherLevel). Interestingly, on the host server itself the effect seems to be 100% unreproducible. I can post a screenshot of this effect if required. You're using XNest? Usually I don't debug problems with XNest which seems to have a lot of bugs. Did you ever see this with a real X server? Yes. It is the same problem which was 100% reproducible with 2.3.28 under XFree86 3.3.2 with Matrox Millenium II (that was my previous machine). And it is still reproducible under XFree86 4.0.3 on our 4-monitor PC (Matrox G450DualHead + 2 x Millenium II), the same problem on any head. That machine has RedHat 6.2 (kernel 2.2.16) with glibc-2.1.3. U... Actually, I ran fvwm over a 100Mbit Ethernet from another machine, and my oldie was P166MMX; so, maybe there's some timing problem? CUT HERE Style FvwmWharf StaysOnTop,Sticky, WindowListSkip,CirculateSkip, \ ClickToFocus, NoTitle,NoHandles,BorderWidth 0 *FvwmWharfAnimate *FvwmWharfAnimateMain *FvwmWharfGeometry -0+0 *FvwmWharfColumns 1 *FvwmWharfTextureType 255 *FvwmWharfBgColor gray51 *FvwmWharf AfterStep AfterStep.xpm Folder *FvwmWharf Shutdown ShutDown.xpm Quit *FvwmWharf xlock KeysOnChain.xpm FvwmForm XLock *FvwmWharf ~Folder *FvwmWharf xclock nil Swallow xclock xclock -bg #8e8a9e -fg \ #3f -geometry 45x45-1-1 -padding 0 *FvwmWharf xbiff nil Swallow xbiff xbiff -bg #8e8a9e -fg \ #3f -geometry 45x45-1-1 *FvwmWharf xload nil Swallow xload xload -nolabel -hl black -bg \ #8e8a9e -geometry 48x48-1-1 *FvwmWharf xload nil Exec xterm -ut -T top -e top *FvwmWharf Pager nil Swallow FvwmPager Module FvwmPager 0 0 *FvwmWharf xterm monitor-check.xpm Exec xterm -bg black -geometry \ 80x25 -sl 500 -sb -ls -T 'xterm: [EMAIL PROTECTED]' *FvwmWharf emacs text.xpm Exec emacs *FvwmWharf gimp 3dpaint.xpm Exec gimp *FvwmWharf pine writeletter.xpm Exec xterm -T pine -e pine *FvwmWharf Netscape netscape3.xpm Exec netscape *FvwmWharf Recycler recycler.xpm Restart fvwm2 CUT HERE _ 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: Xinerama support for IconBox style?
Dominik Vogt fvwm-workers@fvwm.org writes: On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: Is there a way to test screen size changes without Xinerama working? With Xinerama emulation. Run configure with $ ./configure --enable-xinerama-emulation The screen is then split into two fake Xinerama screens and a blank area that doesn't belong to any screen. To switch Xinerama on and off just use Xinerama off or Xinerama on or Xinerama primary_screen_number Hmm, none of these actually change where the icon box is. I tried on, off, 0-3. Ah, I see. You moved the calculations from style.c to icons.c, but they still use the global screen dimensions. Instead, the specified screen has to be stored too. Then, one of the XineramaSupportGet...ScrRect() functions can be called in AutoPlaceIcon() to get the actual size and offset of the screen. Also, the call to XineramaSupportParseGeometry in style.c has to be changed to XineramaSupportParseGeometryWithScreen() so that the screen spec can be stored in the icon box (its a signed integer). When this is completed, the following should work: Xinerama 1 Style * iconbox 100x100-0-0 Next iconify # iconifies on screen 1 Xinerama 0 Next iconify # iconifies on screen 0 Xinerama off Next iconify # iconifies on global screen Yes, I saw how XineramaSupportParseGeometryWithScreen is needed to get the screen number, but I still don't see how the screen number is going to be used. Is it needed by the Iconify command? -- 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: Xinerama support for IconBox style?
On Tue, Aug 21, 2001 at 08:57:20AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: Is there a way to test screen size changes without Xinerama working? With Xinerama emulation. Run configure with $ ./configure --enable-xinerama-emulation The screen is then split into two fake Xinerama screens and a blank area that doesn't belong to any screen. To switch Xinerama on and off just use Xinerama off or Xinerama on or Xinerama primary_screen_number Hmm, none of these actually change where the icon box is. I tried on, off, 0-3. Ah, I see. You moved the calculations from style.c to icons.c, but they still use the global screen dimensions. Instead, the specified screen has to be stored too. Then, one of the XineramaSupportGet...ScrRect() functions can be called in AutoPlaceIcon() to get the actual size and offset of the screen. Also, the call to XineramaSupportParseGeometry in style.c has to be changed to XineramaSupportParseGeometryWithScreen() so that the screen spec can be stored in the icon box (its a signed integer). When this is completed, the following should work: Xinerama 1 Style * iconbox 100x100-0-0 Next iconify # iconifies on screen 1 Xinerama 0 Next iconify # iconifies on screen 0 Xinerama off Next iconify # iconifies on global screen Yes, I saw how XineramaSupportParseGeometryWithScreen is needed to get the screen number, but I still don't see how the screen number is going to be used. Is it needed by the Iconify command? No. Somewhere in icons.c the actual position and size of the icon boxes is calculated. To do this, the global screen dimensions and position (0 0) are used. These values have to be replaced with the screen dimensions of the Xinerama screen that is to be used. All this has to be done every time the Xinerama command is called. 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 support for IconBox style?
On Sun, Aug 19, 2001 at 07:35:15PM -0400, Dan Espen wrote: Dominik Vogt [EMAIL PROTECTED] writes: Dan, I looked at the icon box code in style.c because I wanted to make it work with changes of the Xinerama state, but the matter is too complex to write a patch in short time for me. What I want to do: 1) Default to using the primary screen for icon box specs (already works for X geometry like specs and is easy to do for the other syntax). 2) Recalculate all icon boxes when the Xinerama layout of the screen changes (switched on or off). The difficult part is (2) because all the calculations are done when the style is defined. The precise spec string is thrown away afterwards. So doing this requires to remove the calculations from style.c and do them somewhere is icons.c. Can you take a look at this, please? I think this could wait until after 2.4.1. Done. You may want to test this on a system that supports Xinerama. I tested it with: Style * IconBox -80 240 -1 -1, IconGrid 80 67, \ IconBox 1040x20+0-40, IconGrid 80 80, IconFill r t which tests both formats and some negative coordinates. Great! I am still unsure about a few things that could be done: - Should each screen have a default icon box? - Should icons always be placed in an icon box that overlaps the window's screen first? - Is it worthwhile to prevent icons from being placed between screens if the icon box spans the whole desktop? (I guess not). I already wrote the code to update the icon boxes when the Xinerama layout changes, but it needs yet to be tested. 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: CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
On Sun, 19 Aug 2001, FVWM CVS wrote: Log message: * Applied Xinerama patch for Maximize command but changed syntax to Maximize Screen screen-spec. fvwm.org seems to be offline, so the question: would it be possible to maximize on the same screen where the window currently is? I.e., if the window is completely on screen 2, and I'm issuing Next (WINNAME) Maximize from FvwmCommand on screen 3 (i.e. c==3), the window gets geometry [EMAIL PROTECTED] _ 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: Xinerama support for IconBox style?
On Mon, Aug 20, 2001 at 04:19:19PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Mon, 20 Aug 2001, Dominik Vogt wrote: On Sun, Aug 19, 2001 at 07:35:15PM -0400, Dan Espen wrote: Dominik Vogt [EMAIL PROTECTED] writes: Dan, I looked at the icon box code in style.c because I wanted to make it work with changes of the Xinerama state, but the matter is too complex to write a patch in short time for me. What I want to do: 1) Default to using the primary screen for icon box specs (already works for X geometry like specs and is easy to do for the other syntax). 2) Recalculate all icon boxes when the Xinerama layout of the screen changes (switched on or off). The difficult part is (2) because all the calculations are done when the style is defined. The precise spec string is thrown away afterwards. So doing this requires to remove the calculations from style.c and do them somewhere is icons.c. Can you take a look at this, please? I think this could wait until after 2.4.1. Done. You may want to test this on a system that supports Xinerama. I tested it with: Style * IconBox -80 240 -1 -1, IconGrid 80 67, \ IconBox 1040x20+0-40, IconGrid 80 80, IconFill r t which tests both formats and some negative coordinates. Great! I am still unsure about a few things that could be done: - Should each screen have a default icon box? Yes. The natural way is to place icon on the same screen where the window is. - Should icons always be placed in an icon box that overlaps the window's screen first? Can you please explain what you mean by that? Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. - Is it worthwhile to prevent icons from being placed between screens if the icon box spans the whole desktop? (I guess not). Agreed. If the user makes a global iconbox, his choice should be obeyed. 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: CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
On Mon, Aug 20, 2001 at 04:40:52PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Sun, 19 Aug 2001, FVWM CVS wrote: Log message: * Applied Xinerama patch for Maximize command but changed syntax to Maximize Screen screen-spec. fvwm.org seems to be offline, so the question: would it be possible to maximize on the same screen where the window currently is? I.e., if the window is completely on screen 2, and I'm issuing Next (WINNAME) Maximize from FvwmCommand on screen 3 (i.e. c==3), the window gets geometry [EMAIL PROTECTED] Isn't that the default behaviour of your patch without global? I only changed the syntax of the additional key words: Maximize global ... becomes Maximize screen g ... Im addition you can specify Maximize screen p ... Maximize screen c ... Maximize screen 0 ... Maximize screen 1 ... ... 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 support for IconBox style?
Dominik Vogt fvwm-workers@fvwm.org writes: On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: Is there a way to test screen size changes without Xinerama working? With Xinerama emulation. Run configure with $ ./configure --enable-xinerama-emulation The screen is then split into two fake Xinerama screens and a blank area that doesn't belong to any screen. To switch Xinerama on and off just use Xinerama off or Xinerama on or Xinerama primary_screen_number Hmm, none of these actually change where the icon box is. I tried on, off, 0-3. I'm not sure if they should. I sort of thought if I had on followed by 0, it might use the smaller box on the left as the primary screen but it didn't seem to do that. It must be pretty neat to watch FvwmAnimate draw lines from one screen to another. -- 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: Xinerama support for IconBox style?
Dominik Vogt fvwm-workers@fvwm.org writes: Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. I don't think we'd want to apply the same screen test unless the user indicated that the iconbox was for a specific screen. Right now, theres no way to do that. I don't think that just because the iconbox lies completely within a screen is sufficient reason to only use it for one screen. Since I don't have a setup, I can only guess, but my guess is that we don't need a iconbox for each screen feature. -- 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: Xinerama support for IconBox style?
On Mon, 20 Aug 2001, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. I don't think we'd want to apply the same screen test unless the user indicated that the iconbox was for a specific screen. Right now, theres no way to do that. Would it be possible to remember the screen# together with translated geometry? I don't think that just because the iconbox lies completely within a screen is sufficient reason to only use it for one screen. Since I don't have a setup, I can only guess, but my guess is that we don't need a iconbox for each screen feature. Well, maybe not iconbox for each screen, but iconify on the same screen. It seems most natural that windows iconify on the same screen where they are. A possible way to achieve this behaviour is to define a floating iconbox: i.e. IconBox -80x200-1-1 will create an iconbox which will be treated as @w (w is window's current screen). Not sure about implementation details, though -- I'm speaking of this mainly as a user of several multiheaded machines. BTW, there's a little problem with specifying iconboxes separately for each screen: this is okay for a static configuration, but what about an XDM server which works for several different-headed machines? So there's a need in a single command to bind iconboxes to all screens. I have yet to test the latest CVS, so sorry if everything is already done. _ 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: Xinerama support for IconBox style?
On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: Is there a way to test screen size changes without Xinerama working? With Xinerama emulation. Run configure with $ ./configure --enable-xinerama-emulation The screen is then split into two fake Xinerama screens and a blank area that doesn't belong to any screen. To switch Xinerama on and off just use Xinerama off or Xinerama on or Xinerama primary_screen_number Hmm, none of these actually change where the icon box is. I tried on, off, 0-3. I don't know if you did this, but I only made the X geometry like syntax work with screens. The other syntax still addresses the global screen if you did not write this. Try Style * IconBox [EMAIL PROTECTED] I'm not sure if they should. I sort of thought if I had on followed by 0, it might use the smaller box on the left as the primary screen but it didn't seem to do that. The proper syntax is Xinerama 3 not Xinerama on 3 I guess this should be changed anyway since it interferes with the paring of 0/1 values of the bool argument. 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 support for IconBox style?
Dominik Vogt fvwm-workers@fvwm.org writes: On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: Is there a way to test screen size changes without Xinerama working? With Xinerama emulation. Run configure with ... Hmm, none of these actually change where the icon box is. I tried on, off, 0-3. I don't know if you did this, but I only made the X geometry like syntax work with screens. The other syntax still addresses the global screen if you did not write this. Try Style * IconBox [EMAIL PROTECTED] Neat. Issuing the Style command moves the icons around. It looks good to me. The man page needs work. I'm not sure if they should. I sort of thought if I had on followed by 0, it might use the smaller box on the left as the primary screen but it didn't seem to do that. The proper syntax is Xinerama 3 not Xinerama on 3 I meant to say, I issued: Xinerama on Xinerama 0 I guess this should be changed anyway since it interferes with the parsing of 0/1 values of the bool argument. My biggest problem is spelling the command. -- 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: Xinerama support for IconBox style?
Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] writes: On Mon, 20 Aug 2001, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. I don't think we'd want to apply the same screen test unless the user indicated that the iconbox was for a specific screen. Right now, theres no way to do that. Would it be possible to remember the screen# together with translated geometry? It can be saved, but what for? -- 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]
One more Xinerama patch for FvwmWharf
Hi! This patch deals with withdrawing Wharf to corners and with in which direction panels should open. BTW, there's a strange error in drawing the panel's host button. When a vertical Wharf is at the right border (and a panel slides to the left), after a panel completely appears, the host button is in two halves: the right half is pressed, while the left one is depressed. Presence of this effect depends on X server, but I can 100% reproduce it in Xnest ran on Matrox G450 under XFree86 4.0.3 (RH7.1, AnotherLevel). Interestingly, on the host server itself the effect seems to be 100% unreproducible. I can post a screenshot of this effect if required. BTW2: wouldn't it be wise to add an item 15.5.5.5 to todo-3.0, stating Remove FvwmWharf (It's an FvwmButtons with trivial enhancements)? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics wharf.diff.gz Description: Binary data
Re: Xinerama patch for Maximize
On Sat, Aug 18, 2001 at 06:59:56PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Fri, 17 Aug 2001, Dominik Vogt wrote: On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 16 Aug 2001, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory That's true, but I don't think we would want to develop a second syntax. My idea was to support maximizing/moving/resizing only with the new, X geometry like syntax and phase out the old one. Okay, but there are two issues. First, while the geometry syntax is mathematically okay, it is just too complicated (messy?) for an ordinary user -- like a Perl program for a person which knows only Pascal. I don't want to say that users are silly, but 640pxgrow-5+0p is a bit too much. Well, the ordinary user would not use that syntax at all but stick with Maximize on Maximize on 100 0 Maximize on 0 100 Anyway, as nice as a common syntax for all the resizing/moving commands would be, its not the proper time to do this. BTW, this syntax employs latin letters for three different uses: 1) unit size (p); 2) keywords (grow); 3) times/multiplication operator (x); and all these go without any separators. While this is definitely parseable, it isn't very fancy and is too error-prone. Yes, and my X11 book says: If the [parse]string is not in Host Portable Character Encoding, the result is implementation-dependent. Anyway, can you please post a formal definition of new syntax, like a BNF? No, I can't. I don't even know the correct definition of the standard X11 geometry spec. Sorry for only criticizing, but I yet have to find out some reasonable suggestions. Let's skip my idea for now and update the old syntax. Second, due to compatibility reasons, the old syntax should still be supported. Of course. I only though about not writing new features for the old syntax. 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]
Xinerama support for IconBox style?
Dan, I looked at the icon box code in style.c because I wanted to make it work with changes of the Xinerama state, but the matter is too complex to write a patch in short time for me. What I want to do: 1) Default to using the primary screen for icon box specs (already works for X geometry like specs and is easy to do for the other syntax). 2) Recalculate all icon boxes when the Xinerama layout of the screen changes (switched on or off). The difficult part is (2) because all the calculations are done when the style is defined. The precise spec string is thrown away afterwards. So doing this requires to remove the calculations from style.c and do them somewhere is icons.c. Can you take a look at this, please? I think this could wait until after 2.4.1. 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]
CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/19 09:17:27 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : fvwm2.1 move_resize.c placement.c screen.h update.c virtual.c libs : XineramaSupport.c XineramaSupport.h modules/FvwmIconMan: x.c modules/FvwmTaskBar: FvwmTaskBar.c modules/FvwmWinList: FvwmWinList.c Log message: * Applied Xinerama patch for Maximize command but changed syntax to Maximize Screen screen-spec. -- 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 patches complete
With the latest commits, I think Xinerama support is complete. It needs a bit polishing of the documentation, thoug. Probably a separate Xinerama section in the man page is a good idea. Everybody is welcome to help testing the patches, specifically Xinerama placement of modules, new module options and the changes in fvwm's core. All changes are listed in the NEWS file. 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 support for IconBox style?
Dominik Vogt [EMAIL PROTECTED] writes: Dan, I looked at the icon box code in style.c because I wanted to make it work with changes of the Xinerama state, but the matter is too complex to write a patch in short time for me. What I want to do: 1) Default to using the primary screen for icon box specs (already works for X geometry like specs and is easy to do for the other syntax). 2) Recalculate all icon boxes when the Xinerama layout of the screen changes (switched on or off). The difficult part is (2) because all the calculations are done when the style is defined. The precise spec string is thrown away afterwards. So doing this requires to remove the calculations from style.c and do them somewhere is icons.c. Can you take a look at this, please? I think this could wait until after 2.4.1. It doesn't look too hard, it just needs to save the signs separately (for -0) and apply screen dimensions later. Is there a way to test screen size changes without Xinerama working? I did a CVS update, now I have this: Undefined first referenced symbol in file XineramaSupportGetNumberedScrRect placement.o -- 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: Xinerama support for IconBox style?
Oops, ignore that comment about XineramaSupportGetNumberedScrRect. -- 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: Xinerama patch for Maximize
On Fri, 17 Aug 2001, Dominik Vogt wrote: On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 16 Aug 2001, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory That's true, but I don't think we would want to develop a second syntax. My idea was to support maximizing/moving/resizing only with the new, X geometry like syntax and phase out the old one. Okay, but there are two issues. First, while the geometry syntax is mathematically okay, it is just too complicated (messy?) for an ordinary user -- like a Perl program for a person which knows only Pascal. I don't want to say that users are silly, but 640pxgrow-5+0p is a bit too much. BTW, this syntax employs latin letters for three different uses: 1) unit size (p); 2) keywords (grow); 3) times/multiplication operator (x); and all these go without any separators. While this is definitely parseable, it isn't very fancy and is too error-prone. Anyway, can you please post a formal definition of new syntax, like a BNF? Sorry for only criticizing, but I yet have to find out some reasonable suggestions. Second, due to compatibility reasons, the old syntax should still be supported. Otherwise most users of =2.4 (especially those with 1 monitor) will live with old versions, and in some cases even fvwmNN_convert wouldn't be able to help them (think about AnotherLevel and alikes). _ 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: Xinerama patch for Maximize
On Thu, 16 Aug 2001, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory -- yours allows more flexibility, while the logic im my patch is required in case when no parameters are specified (i.e. just Maximize) or the old syntax is used (incl. e.g. grow). But, of course, with some efforts old syntax parser can be changed to generate an appropriate on geometry spec. There's a pitfall in geometry syntax for Maximize: what would mean Maximize [EMAIL PROTECTED] if applied to a window on different page/desk? Would it be current screen where the *pointer* is, or the screen, where that *window* is (more precisely, where it *would* be when Focus applied)? And what to do in case when current page doesn't start on a page boundary? _ 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: Xinerama patch for Maximize
On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 16 Aug 2001, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory That's true, but I don't think we would want to develop a second syntax. My idea was to support maximizing/moving/resizing only with the new, X geometry like syntax and phase out the old one. -- yours allows more flexibility, while the logic im my patch is required in case when no parameters are specified (i.e. just Maximize) or the old syntax is used (incl. e.g. grow). But, of course, with some efforts old syntax parser can be changed to generate an appropriate on geometry spec. Basically, the parser would have to do the same as the non geometry based dimension/position parsers we have. For each bit of the geometry spec it should optionally accept a suffix to the number, e.g. 100px100p+0m+0m, and possibly a list of key words. This way it would finally possible to have something like this: Maximize 640pxgrow-5+0p (maximized window is placed 5% of the screen width off the right border and ant the top of the screen with a width of 640 pixels and whatever height fits). Of course this requires a pre parsing pass over the geometry string that filters out all the fancy suffices and key words before calling ...ParseGeometry. int FancyParseGeometry( char *geom, int *ret_x, int *ret_y, int *ret_w, int *ret_h, char *xy_suffix_array, int *xy_units_array, char **xy_keywords, int *ret_x_unit, int *ret_y_unit, char *wh_suffix_array, int *wh_units_array, char **wy_keywords, int *ret_w_unit, int *ret_h_unit, int *ret_w_keyword, int *ret_h_keyword); Pretty complex I guess, but very useful. There's a pitfall in geometry syntax for Maximize: what would mean Maximize [EMAIL PROTECTED] if applied to a window on different page/desk? Would it be current screen where the *pointer* is, or the screen, where that *window* is (more precisely, where it *would* be when Focus applied)? And what to do in case when current page doesn't start on a page boundary? As usual, @c would address the screen that contains the pointer, possibly projected to other pages or desks. To force the window into the current viewport, the MoveToDesk/Page/Screen commands can be used. 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 patch for Maximize
On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! This patch touches solely the move_resize.c. I've tried to modify fvwm2.1, but my roff skills seem to be below what required to keep Maximize description in the same style (the latter seems a bit wrong BTW -- too many spaces). I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. There are some problems with maximizing windows that aren't on the current page when the page itself doesn't start on a page boundary, but that effect existed before anyway. I see. Consider it fixed :) And there is a comment maximize on visible page after IsRectangleOnThisPage() check, which doesn't seem to be correct -- somehow it happens that windows are maximized on visible page even if they are by some part (not entirely) on it. The comment should better read: maximize on the page where the center of the window is, but if any part of the window is on the current page, maximize it there. BTW, Dominik, was it done intentionally that in Xinerama emulation mode the vertical separator doesn't separate, but in fact overlaps two left pixels of the second pseudo-screen? The result seems a bit confusing ;-) You would have to ask Olivier. He wrote that stuff. Anyway, I don't really care about this. It is only meant as visible feedback for testing and debugging. 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]
Xinerama patch for Maximize
Hi! This patch touches solely the move_resize.c. I've tried to modify fvwm2.1, but my roff skills seem to be below what required to keep Maximize description in the same style (the latter seems a bit wrong BTW -- too many spaces). I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). There are some problems with maximizing windows that aren't on the current page when the page itself doesn't start on a page boundary, but that effect existed before anyway. And there is a comment maximize on visible page after IsRectangleOnThisPage() check, which doesn't seem to be correct -- somehow it happens that windows are maximized on visible page even if they are by some part (not entirely) on it. BTW, Dominik, was it done intentionally that in Xinerama emulation mode the vertical separator doesn't separate, but in fact overlaps two left pixels of the second pseudo-screen? The result seems a bit confusing ;-) _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics maximize.diff.gz Description: Binary data
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]
CVS domivogt fvwm-web: * Updated Xinerama module interface description.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: domivogt01/08/11 03:28:36 Modified files: . : ChangeLog mod_f2m_communication.html Log message: * Updated Xinerama module interface description. -- 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]
CVS domivogt: * Finished Xinerama support for modules.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/11 16:28:18 Modified files: . : todo-xinerama libs : XineramaSupport.c modules: ChangeLog modules/FvwmButtons: FvwmButtons.c modules/FvwmIconMan: FvwmIconMan.1 FvwmIconMan.c FvwmIconMan.h fvwm.c globals.c readconfig.c x.c modules/FvwmIdent: FvwmIdent.c modules/FvwmPager: FvwmPager.c x_pager.c modules/FvwmWinList: FvwmWinList.c FvwmWinList.h Log message: * Finished Xinerama support for modules. * Fixedtransient option of FvwmPager. * Allow Transient as well as -Transient in various modules. -- 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]
CVS domivogt: * Added Xinerama support in FvwmRearrange, FvwmIdent and FvwmScroll.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/06 17:50:22 Modified files: . : todo-xinerama fvwm : placement.c modules: ChangeLog modules/FvwmIdent: FvwmIdent.c Makefile.am modules/FvwmRearrange: FvwmRearrange.c Makefile.am modules/FvwmScript: FvwmScript.c Makefile.am modules/FvwmScroll: FvwmScroll.c GrabWindow.c Log message: * Added Xinerama support in FvwmRearrange, FvwmIdent and FvwmScroll. -- 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]
