Home / Browse / PLWM / Mail / Archive

PLWM

Email Archive: plwm-hackers (read-only)

2001:	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov (2)	_Dec (80)
2002:	_Jan (15)	_Feb (22)	_Mar (21)	_Apr (9)	_May (1)	_Jun	_Jul (6)	_Aug	_Sep	_Oct (1)	_Nov	_Dec
2003:	_Jan (7)	_Feb (1)	_Mar	_Apr (2)	_May	_Jun (1)	_Jul (1)	_Aug	_Sep	_Oct	_Nov (1)	_Dec
2004:	_Jan (1)	_Feb	_Mar (16)	_Apr (6)	_May (1)	_Jun (1)	_Jul	_Aug	_Sep	_Oct (4)	_Nov (6)	_Dec (1)
2005:	_Jan	_Feb	_Mar	_Apr (3)	_May	_Jun	_Jul (3)	_Aug (8)	_Sep (1)	_Oct	_Nov (2)	_Dec
2006:	_Jan (3)	_Feb	_Mar (5)	_Apr (5)	_May (3)	_Jun	_Jul (2)	_Aug	_Sep (7)	_Oct (3)	_Nov	_Dec
2007:	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul (19)	_Aug	_Sep	_Oct (2)	_Nov	_Dec
2008:	_Jan	_Feb (34)	_Mar (28)	_Apr (23)	_May (13)	_Jun	_Jul (11)	_Aug	_Sep (3)	_Oct	_Nov	_Dec (14)
2009:	_Jan (12)	_Feb (3)	_Mar (1)	_Apr (2)	_May (5)	_Jun (7)	_Jul	_Aug	_Sep (4)	_Oct	_Nov (7)	_Dec
2011:	_Jan	_Feb	_Mar (1)	_Apr	_May	_Jun	_Jul (1)	_Aug (1)	_Sep	_Oct	_Nov	_Dec (1)
2012:	_Jan	_Feb (1)	_Mar	_Apr (5)	_May (4)	_Jun (4)	_Jul (4)	_Aug	_Sep (3)	_Oct (1)	_Nov (1)	_Dec (1)
2013:	_Jan (2)	_Feb (1)	_Mar (1)	_Apr (1)	_May (3)	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec


S	M	T	W	T	F	S
					1	2

3	4	5	6	7	8	9

10	11	12	13	14	15	16
					(2)
17	18	19	20	21	22	23
(1)	(1)		(3)
24	25	26	27	28	29	30

[Plwm-hackers] Making plwm xinerama-aware

From: Mike Meyer <mwm@mi...> - 2006-09-20 03:38

I guess the first question is - does anyone besides me even care? If
not, then I'll just do it my way...

Anyway, I've got enough of a xinerama extension for python-xlib
working that I can make plwm xinerama-aware. I'm looking for thoughts
on the best way to do this.

For those who aren't familiar with it, xinerama is an extension that
makes a multi-screen system look like it has one screen. Without it,
multiple screens might as well be on different servers, as you can't
move windows back and forth between them. Xinerama wraps a rectangle
around the screens as configured, and then presents that rectangle as
the sole screen to the clients, allowing windows to be moved between
them at will. This has two problems: 1) the screen may have "dead
space" in it, which isn't visible on any monitor. A non-Xinerama aware
window manager might open a window there, which would be
problematical. 2) The geometry looks like one screen. Things that
expand to full screen size will cover both monitors. Things that try
to center on two identical monitor will open across the divide.

The extension deals with this by providing a way to get a list of
monitors and their geometry. An application that's Xinerama-aware will
use the geometry for the appropriate monitor instead of the actual
screen geometry.

The goal in making plwm xinerama aware is to make taking advantage of
it as painless as possible for window managers. For my usage, screens
primarily have two uses: filtering the server client list, so you only
get clients that can open on the screen in question, and doing
geometry calculations based on the screen. In a Xinerama environment,
the former would normally want to use the screen information, and the
latter the monitor geometry.

The wmmanager.screen class already has root_x, root_y, root_width and
root_height (and root_full_width and root_full_height, but I don't see
used for anything). My proposal is to provide a "monitor" facade for
each monitor in a Xinerama screen. The monitor class will provide the
root_x, root_y, root_width and root_height values for the monitor. It
will also provide root_screen as a reference to the real screen. Any
other attribute requests will be passed on to root_screen. When a
window is created in a Xinerama environment, it's screen attribute
will be connected to the appropriate monitor instead of a screen.

This way, the most common things one wants the geometry or filtering
for will get the "right" version without having to change the code.
Places that want the "other" information - that want the screen
geometry instead of the geometry of the monitor, or actually want to
deal only with clients on the current monitor - will have to be
changed to deal with it. Code that assumes that the root of a screen
is always at position 0, 0 will need to be changed. Code that moves
windows will have to be modified to deal with the fact that th screen
they refer to can change during the move. That code might also want to
do something special about monitor edges, like snapping to them.

That's the general idea. Anyone got any comments? Question? 
Suggestions?

	Thanks,
	<mike
-- 
Mike Meyer <mwm@...>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

Re: [Plwm-hackers] Making plwm xinerama-aware

From: Peter Liljenberg <peter.liljenberg@gm...> - 2006-09-20 21:04

> I guess the first question is - does anyone besides me even care? If
> not, then I'll just do it my way...

As my neck hurts when I try to use more than one screen, I can't say
that I care out of a specific interest, but it's an interesting
technology.

> The wmmanager.screen class already has root_x, root_y, root_width and
> root_height (and root_full_width and root_full_height, but I don't see
> used for anything).

Note that root_x etc are the usable part of the root, minus the edge
area reserved by any mixins.  Currenly only the modewindow uses that.

> My proposal is to provide a "monitor" facade for
> each monitor in a Xinerama screen. The monitor class will provide the
> root_x, root_y, root_width and root_height values for the monitor. It
> will also provide root_screen as a reference to the real screen. Any
> other attribute requests will be passed on to root_screen. When a
> window is created in a Xinerama environment, it's screen attribute
> will be connected to the appropriate monitor instead of a screen.

A quite radical twist: could the xinerama model with a single root
window consisting of multiple monitors also model the classic X
multi-screen?  In that case we could get rid of today's Screen class
and replace it with monitor-aware code.

The problems are non-trivial, though: the code that presents multiple
screens as a single one would have to enforce that windows can't be
moved off a monitor, need to find out the monitor configuration, and
there's the problem that different screens may have completely
different visuals and color maps.

Maybe not something to be done in a 2.X release, though...

/Peter Liljenberg

Re: [Plwm-hackers] Making plwm xinerama-aware

From: Mike Meyer <mwm@mi...> - 2006-09-20 21:37

In <383f32ef0609201404i5a71d459h674e314b83ef7bae@...>, Peter Liljenberg <peter.liljenberg@...> typed:
> > The wmmanager.screen class already has root_x, root_y, root_width and
> > root_height (and root_full_width and root_full_height, but I don't see
> > used for anything).
> Note that root_x etc are the usable part of the root, minus the edge
> area reserved by any mixins.  Currenly only the modewindow uses that.

Ah, excellent. So I need to add root_full_x and root_full_y, because
full-screen might not have 0, 0 as the origin. And code that uses
root_width and root_height and assumes that root_x and root_y are 0
is already broken.

> > My proposal is to provide a "monitor" facade for
> > each monitor in a Xinerama screen. The monitor class will provide the
> > root_x, root_y, root_width and root_height values for the monitor. It
> > will also provide root_screen as a reference to the real screen. Any
> > other attribute requests will be passed on to root_screen. When a
> > window is created in a Xinerama environment, it's screen attribute
> > will be connected to the appropriate monitor instead of a screen.
> A quite radical twist: could the xinerama model with a single root
> window consisting of multiple monitors also model the classic X
> multi-screen?  In that case we could get rid of today's Screen class
> and replace it with monitor-aware code.

Hmm. That might be useful in some strange circumstances (like a
dual-head card that can't be configured as two distinct X screens),
but normally you'd just not turn on Xinerama in your X server to get
that behavior. Usually, people with two monitors turn on Xinerama so
they can move windows between them. That's what's caused me to look
into Xinerama - my second monitor is now useful for more than one
window at a time, so I find myself wanting to move windows between the
two.

> The problems are non-trivial, though: the code that presents multiple
> screens as a single one would have to enforce that windows can't be
> moved off a monitor, need to find out the monitor configuration, and
> there's the problem that different screens may have completely
> different visuals and color maps.

The Xinerama extension (I checked that into python-xlib's CVS earlier
today) lets you get the monitor configuration:

>>> from Xlib.display import Display
>>> d = Display()
>>> d.xinerama_query_screens()
<Xlib.ext.xinerama.QueryScreens serial = 6, data = {'screens': [Xlib.protocol.rq.DictWrapper({'y': 0, 'x': 0, 'height': 1200, 'width': 1600}), Xlib.protocol.rq.DictWrapper({'y': 0, 'x': 1600, 'height': 1200, 'width': 1920})], 'number': 2L, 'sequence_number': 6}, error = None>
>>> 

Xinerama will only let you put two screens together if they have the
same depth. I've not played with colormaps and the like, but I suspect
that those will be forced to stay in sync because there aren't objects
in X to let you manipulate them individually.

> Maybe not something to be done in a 2.X release, though...

Possibly. What I'm doing definitely has a hackish quality to it. Then
again, Xinerama as a whole has that feeling. My next task is to find
documentation on how the Xinerama requests are supposed to behave.

	Thanks,
	<mike
-- 
Mike Meyer <mwm@...>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

[Plwm-hackers] CVS: plwm/plwm panes.py,1.20,1.21

From: Mike Meyer <mwm@us...> - 2006-09-18 21:43

Update of /cvsroot/plwm/plwm/plwm
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26251

Modified Files:
	panes.py 
Log Message:
Remove handling of RemoveClient. This was a nop prior to wmanager. 1.27, and breaks with 1.27.

Index: panes.py
===================================================================
RCS file: /cvsroot/plwm/plwm/plwm/panes.py,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** panes.py	27 Mar 2004 04:18:28 -0000	1.20
--- panes.py	18 Sep 2006 21:43:28 -0000	1.21
***************
*** 207,211 ****
          my.dispatch.add_handler(X.UnmapNotify, my.panes_unmap)
          my.dispatch.add_handler(X.DestroyNotify, my.panes_unmap)
-         my.dispatch.add_handler(wmevents.RemoveClient, my.panes_unmap)
  
      def panes_unmap(my, event):
--- 207,210 ----

[Plwm-hackers] CVS: plwm/plwm wmanager.py,1.27,1.28

From: Mike Meyer <mwm@us...> - 2006-09-17 04:07

Update of /cvsroot/plwm/plwm/plwm
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10647

Modified Files:
	wmanager.py 
Log Message:
Fix a typo in a comment

Index: wmanager.py
===================================================================
RCS file: /cvsroot/plwm/plwm/plwm/wmanager.py,v
retrieving revision 1.27
retrieving revision 1.28
diff -C2 -d -r1.27 -r1.28
*** wmanager.py	16 Jan 2006 21:21:49 -0000	1.27
--- wmanager.py	17 Sep 2006 04:07:51 -0000	1.28
***************
*** 930,934 ****
  	    return
  
! 	# If it is a Client obejct, post a RemoveClient event.  As
  	# that will not reach the client object, dispatch it manually.
  	# Also, this must be done before withdrawing the window, as
--- 930,934 ----
  	    return
  
! 	# If it is a Client object, post a RemoveClient event.  As
  	# that will not reach the client object, dispatch it manually.
  	# Also, this must be done before withdrawing the window, as

[Plwm-hackers] CVS: plwm/plwm pane_utilities.py,1.4,1.5

From: Mike Meyer <mwm@us...> - 2006-09-15 06:06

Update of /cvsroot/plwm/plwm/plwm
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13848/plwm

Modified Files:
	pane_utilities.py 
Log Message:
Update plpwm.py example for dual heads. Tweak pane_utilities so browsers launch on the active screen.

Index: pane_utilities.py
===================================================================
RCS file: /cvsroot/plwm/plwm/plwm/pane_utilities.py,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** pane_utilities.py	19 Jul 2006 22:16:47 -0000	1.4
--- pane_utilities.py	15 Sep 2006 06:06:26 -0000	1.5
***************
*** 20,23 ****
--- 20,24 ----
  #    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  
+ from os import environ
  import cfilter
  from webbrowser import open_new
***************
*** 141,144 ****
--- 142,146 ----
              my.browser(query)
          else:
+             environ['DISPLAY'] = my.pane.screen.displaystring
              open_new(query)

[Plwm-hackers] CVS: plwm/examples plpwm.py,1.41,1.42

From: Mike Meyer <mwm@us...> - 2006-09-15 06:06

Update of /cvsroot/plwm/plwm/examples
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13848/examples

Modified Files:
	plpwm.py 
Log Message:
Update plpwm.py example for dual heads. Tweak pane_utilities so browsers launch on the active screen.

Index: plpwm.py
===================================================================
RCS file: /cvsroot/plwm/plwm/examples/plpwm.py,v
retrieving revision 1.41
retrieving revision 1.42
diff -C2 -d -r1.41 -r1.42
*** plpwm.py	19 Jul 2006 22:16:47 -0000	1.41
--- plpwm.py	15 Sep 2006 06:06:26 -0000	1.42
***************
*** 151,158 ****
          runcommand(my.wm.panes_list[my.wm.panes_current], paneWindow)
  
-     def M4_a(my, event):
-         getapp(my.wm.panes_list[my.wm.panes_current],
-                ".aw", "applix -wp")
- 
      def M4_b(my, event):
          getapp(my.wm.panes_list[my.wm.panes_current], "w3m")
--- 151,154 ----
***************
*** 221,224 ****
--- 217,225 ----
          getapp(my.wm.panes_list[my.wm.panes_current], 'Mozilla[^ ]', 'mozilla')
  
+     def M4_o(my, event):
+         getapp(my.wm.panes_list[my.wm.panes_current], 'OpenOffice.org',
+                'openoffice.org')
+     M4_n = M4_o		# Mac compatability (Neooffice vs. Opera)
+ 
      def M4_p(my, event):
          websearch(my.wm.panes_list[my.wm.panes_current], MyEditHandler,
***************
*** 282,286 ****
                    "Maximize (1)": (my.M4_1, (event,)),
                    "Command (!)": (my.M4_exclam, (event,)),
-                   "Applix Mail (a)": (my.M4_a, (event,)),
                    "Browser (b)": (my.M4_b, (event,)),
                    "Clipboard (c)": (my.M4_c, (event,)),
--- 283,286 ----
***************
*** 325,332 ****
      def a(my, event):
          appmenu(my.wm.panes_list[my.wm.panes_current],
!                 {'words': 'applix -wp',
!                  'clipboard': 'xclipboard',
!                  'sql': 'applix -db',
!                  'sheet': 'applix -ss',
                   'fxtv': 'fxtv',
                   'w3m': 'w3m',
--- 325,329 ----
      def a(my, event):
          appmenu(my.wm.panes_list[my.wm.panes_current],
!                 {'clipboard': 'xclipboard',
                   'fxtv': 'fxtv',
                   'w3m': 'w3m',
***************
*** 404,408 ****
      pane = wm.panes_list[0]
      pane.maximize()
!     #wm.panes_list[1].maximize()
  
      # Disconnect all windows from panes to avoid displaying everything
--- 401,405 ----
      pane = wm.panes_list[0]
      pane.maximize()
!     wm.panes_list[1].maximize()
  
      # Disconnect all windows from panes to avoid displaying everything
***************
*** 410,463 ****
      for c in wm.query_clients():
          c.panes_pane = None
-     pane.window = None
- 
- #    pane.vertical_split()
- #    wm.panes_number(0)
- #    wm.panes_goto(2)
- #    pane.horizontal_split(.0625)
- #    pane.vertical_split(.75)
- #    wm.panes_number(1)
- #    pane = wm.panes_list[1]
- #    pane.horizontal_split(94. / 225.)
- #    wm.panes_number(3)
- #    pane.horizontal_split()
- #    wm.panes_number(2)
- #    wm.panes_goto(5)
- #    wm.panes_number(4)
- #    wm.panes_goto(6)
- #    wm.panes_number(5)
- #    pane = wm.panes_list[6]
- #    pane.horizontal_split(16. / 45.)
- #    pane.horizontal_split(24. / 29.)
- #    wm.panes_number(6)
- #    wm.panes_goto(0)
- #    wm.panes_restore()
  
  
      pane.vertical_split()
!     wm.panes_number(0)
!     wm.panes_goto(1)
!     pane.horizontal_split(.0625)
      pane.vertical_split(.75)
!     wm.panes_number(1)
!     pane = wm.panes_list[1]
!     pane.horizontal_split(94. / 225.)
!     wm.panes_number(3)
      pane.horizontal_split()
      wm.panes_number(2)
!     wm.panes_goto(5)
      wm.panes_number(4)
!     pane = wm.panes_list[5]
!     pane.horizontal_split(25. / 29.)
!     wm.panes_number(6)
  
!     # 524 bhuda 362 student 921 total
!     pane = wm.panes_list[6]
!     pane.horizontal_split(.43)
!     #wm.panes_number(7)
      wm.panes_goto(0)
      wm.panes_restore()
  
- 
  if __name__ == '__main__':
      wmanager.main(PLPWM)
--- 407,450 ----
      for c in wm.query_clients():
          c.panes_pane = None
  
+     # Disconnect the two remaining panes from their windows as well.
+     pane.window = None
+     wm.panes_list[1].window = None
  
+     # Create the panes
      pane.vertical_split()
!     pane.horizontal_split(.06)
      pane.vertical_split(.75)
!     pane.horizontal_split(.37)
!     pane.horizontal_split(.77)
!     pane = wm.panes_list[4]
!     pane.horizontal_split(.42)
      pane.horizontal_split()
+ 
+     # Now number them.
+     wm.panes_goto(2)
+     wm.panes_number(0)
+     wm.panes_goto(4)
+     wm.panes_number(1)
+     wm.panes_goto(8)
      wm.panes_number(2)
!     wm.panes_goto(7)
!     wm.panes_number(3)
!     wm.panes_goto(7)
      wm.panes_number(4)
!     wm.panes_goto(8)
!     wm.panes_number(5)
!     #wm.panes_goto(6)
!     #wm.panes_number(6)
!     wm.panes_goto(8)
!     wm.panes_number(7)
!     
!     # Set up the second screen
!     wm.panes_list[8].vertical_split()
  
!     # And make the world sane
      wm.panes_goto(0)
      wm.panes_restore()
  
  if __name__ == '__main__':
      wmanager.main(PLPWM)