You are not logged in.

#51 2009-09-08 19:59:15

x0rg
Member
From: Switzerland
Registered: 2009-07-12
Posts: 116

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

The error shows up as soon as I do a keystroke (eg ALT-A)

Here's my pytylerc:

#===============================================================================
# PyTyle - A manual tiling manager
# Copyright (C) 2009  Andrew Gallant <andrew@pytyle.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#===============================================================================

"""
.pytylerc

The configuration file for PyTyle. See below for further instructions.
"""

"""
IMPORTANT!

This *IS* a Python file, and therefore, it must be valid Python syntax.
If you get the syntax wrong here, PyTyle will not start.
"""


#------------------------------------------------------------------------------
# MISCELLANEOUS OPTIONS
#------------------------------------------------------------------------------
Config.MISC = {
               # This is a list of all available tilers. If a tiler
               # is not listed here, it cannot be used. They are
               # loaded when PyTyle starts.
               'tilers': ['Vertical', 'Horizontal', 'Maximal'],
               
               # This timeout is used several times in the main event
               # loop. It is the amount of time we wait, for example,
               # between when a new window is created and when we scan
               # for new windows. I imagine that if you have a slower
               # system, you might want to increase this.
               #
               # Note: Using a timeout seems like a hack. Any better
               # ideas?
               #
               # Note 2: I tested this on my P3 1.0 GHz with 128MB
               # of memory, and this value worked fine.
               'timeout': 0.1,
               
               # Toggles window decorations. I don't not recommend
               # currently disabling window decorations, as it's
               # quite experimental. It could also be removed in the
               # future, because without decorations, it is difficult
               # to tell which window is active (usually).
               #
               # Note: I haven't research this yet, but how easy is
               # it to draw borders around windows (XMonad style)?
               'decorations': True,
               }


#------------------------------------------------------------------------------
# KEY BINDINGS
#------------------------------------------------------------------------------

# Key binding format:
# [Alt-][Shift-][Ctrl-][Super-]KEY
#
# Where you can use any combination of modifiers. And KEY is:
# 
# Any letter or number. There are also names for special keys.
#
# I don't have a complete listing yet. I'll put it here soon.
# In general, you can use pretty much any key, but it has 
# to be recognized by Xlib. (For instance, "comma" and not "," 
# and not "Comma" even.)
#
# If you need a list, check out your Python Xlib library,
# probably located somewhere like...
# /usr/lib/python2.x/site-packages/Xlib/keysymdef/
# Specifically, see "miscellany.py" and "latin1.py"
#
# Note: I haven't been able to get the F([1-9]|(1[0-2]) keys
# to work yet. (Although, I've only tried in OpenBox.)
#
# Note 2: If you've used XMonad, you'll feel right as rain!
# I started on Arch with XMonad, and moved to OpenBox,
# so naturally, the key bindings clone XMonad's.
# 
Config.KEYMAP = {
                 # This will enable and tile the current *screen*.
                 # It will also re-tile when pressed. You can
                 # only access the rest of the key bindings if
                 # you've enabled tiling on the current screen.
                 # (Although I'm thinking of changing this for
                 # screen[0-2]_focus.)
                 'Alt-A': Tile.tile,
                 
                 # This will disable and untile the current
                 # *screen*. PyTyle tries to remember the original
                 # positions and sizes of all tiled windows,
                 # although it isn't quite perfect yet. (Specifically,
                 # if you have more than one screen.) 
                 'Alt-U': Tile.untile,
                 
                 # This will cycle through all available tiling
                 # algorithms. By default, there are currently only
                 # two: Vertical and Horizontal. (If you know Python,
                 # I have made it stupidly easy to add tiling
                 # algorithms. Check out the core Tile.py, and then
                 # Tilers/TileDefault.py which provides common methods 
                 # to both Tilers/Horizontal.py and Tilers/Vertical.py.)
                 'Alt-Z': Tile.cycle_tiler,
                 
                 # This is a hard reset of the current screen. It will
                 # force a re-tile and refresh PyTyle's image of the
                 # current screen. It will keep the same tiling
                 # algorithm, however.
                 'Alt-Shift-space': Tile.reset,
                 
                 # This will cycle all slave windows through the
                 # master area. (If there is more than one master
                 # window, it will use the first master window.)
                 'Alt-C': Tile.cycle,
                 
                 # The following three will simply put *focus* on to
                 # the last active window of the specified screen.
                 # Remember, these currently only work properly if
                 # tiling is enabled on the screen.
                 'Alt-W': Tile.screen0_focus,
                 'Alt-E': Tile.screen1_focus,
                 'Alt-R': Tile.screen2_focus,
                 
                 # The following three will move the currently focused
                 # window to the specified screen.
                 'Alt-Shift-W': Tile.screen0_put,
                 'Alt-Shift-E': Tile.screen1_put,
                 'Alt-Shift-R': Tile.screen2_put,
                 
                 # The following two will increase and decrease the master
                 # area. Depending on the tiling algorithm, these could
                 # be irrelevant or do different things. (For instance,
                 # in the Vertical layout, it will change the master area
                 # width, and in the Horizontal layout, it will change the
                 # master area height.)
                 'Alt-H': Tile.master_decrease,
                 'Alt-L': Tile.master_increase,
                 
                 # The following two will increase and decrease the number
                 # of master windows. This will allow you to easily configure
                 # a grid layout dynamically, among other things.
                 'Alt-period': Tile.add_master,
                 'Alt-comma': Tile.remove_master,
                 
                 # This will make the currently active window the master.
                 'Alt-Return': Tile.make_active_master,
                 
                 # This will move focus to the master window (or the first
                 # master window if there are more than one).
                 'Alt-M': Tile.win_master,
                 
                 # This will close the currently focused window. You do
                 # *NOT* need to use this to close windows. It is only
                 # included here for completeness. (In other words, you
                 # can close a window any way you like, minimize to
                 # tray, etc.)
                 'Alt-Shift-C': Tile.win_close, 
                 
                 # The following two will cycle focus to the previous or
                 # next windows. (The algorithm for this is determined
                 # by the current tiling layout.)
                 'Alt-J': Tile.win_previous,
                 'Alt-K': Tile.win_next,
                 
                 # The following two will switch the current window with
                 # the previous or next window.
                 'Alt-Shift-J': Tile.switch_previous,
                 'Alt-Shift-K': Tile.switch_next,
                 
                 # This will maximize all windows on the screen that
                 # PyTyle is managing. Note that currently, while you
                 # can use the next/previous window commands when all
                 # are maximized, other commands could be quite
                 # unpredictable. I'll be working on this soon.
                 'Alt-X': Tile.max_all,
                 
                 # This will restore (or unmaximize) all windows on the
                 # screen that PyTyle is managing.
                 'Alt-S': Tile.restore_all,
                 
                 # This is a debugging binding that shows some information
                 # about the current desktop. It's only useful if you're
                 # running PyTyle from a terminal.
                 #'Alt-D': Tile.query,
                 }


#------------------------------------------------------------------------------
# DOCKS, PANELS, ETC...
#------------------------------------------------------------------------------

# This will allow you to forcefully tell PyTyle about any docks/panels that
# you may have. If you have a basic setup (read: one screen), then I would
# advise that you ignore this for now, and only configure this if you notice
# that PyTyle is putting windows over your docks/panels.
#
# However, if you have two or more screens and have docks/panels, you *MUST*
# configure this, otherwise PyTyle will use the entirety of your screens.
# The problem here is that with xinerama, it's only going to tell you the
# x/y/width/height of each screen, and the window manager isn't much more
# help. (Especially since they aren't required to broadcast their struts
# or partial struts, to my knowledge. If I had that information, I might be
# able to eliminate this configuration.)
#
# The configuration is pretty straight-forward. See the commented out example
# for a sample. (Which will create even margins around the tiling windows
# for two screens. It's actually kind of neat looking. Try it.)
#
# Note: If you have this set and you only have one screen, it will override
# the workarea reported by your window manager.
Config.WORKAREA = {}

# Pretty straight forward here. Just use the screen number as your key,
# (starting from zero) and specify *all four* of the configuration 
# options: top, bottom, left, and right. Each value should be the number 
# of pixels from the edge of the screen that PyTyle should ignore.
#Config.WORKAREA = {                   
#                   0: {
#                       'top': 100,
#                       'bottom': 100,
#                       'left': 100,
#                       'right': 100,
#                       },
#                   1: {
#                       'top': 200,
#                       'bottom': 200,
#                       'left': 200,
#                       'right': 200,
#                       }, 
#                   }


#------------------------------------------------------------------------------
# IGNORE WINDOW LIST
#------------------------------------------------------------------------------

# This is a simple list of windows that PyTyle should exclude from
# tiling. It's case-insensitive and will search the name and class
# of the window. (This search algorithm could change, as I haven't 
# put much thought into it.)
#
# Note: This is useful for things like run dialogs and other quick
# popups that PyTyle can't detect. (It will, however, detect popups
# within other windows.) Also useful for applications like Gimp.
#
# Note 2: You shouldn't need to put dmenu here.
Config.FILTER = [
               'gmrun', 'gimp', 'download' 'feh',
               ]


#------------------------------------------------------------------------------
# TILING PER WORKSPACE/SCREEN
#------------------------------------------------------------------------------

# This will let you configure the default tiling algorithms on a
# per screen per workspace basis. A default tiler must be set.
# Also, see the commented out configuration for an example.
#
# Remember: You can always cycle through the different tiling
# algorithms after the initial tile.
Config.TILING = {
               'default': 'Vertical',
               }

# This configuration sets the default tiler to "Vertical", and the
# default tiler of Screen 1 to "Horizontal" (so all desktops on
# Screen 1 will have a horizontal layout at first). Also, this will
# set the default layout on Screen 0 for desktops 4 and 6 to
# "Horizontal".
#
# Note: Screen and desktop numbers start from 0. So desktop 4 should
# be configured using "3" below.
#Config.TILING = {
#                 'default': 'Vertical',
#                 0: {
#                       5: 'Horizontal',
#                       7: 'Horizontal',
#                    },
#                 1: 'Horizontal',
#                 }

Offline

#52 2009-09-08 20:21:56

Wintervenom
Member
From: /home/wintervenom
Registered: 2008-08-20
Posts: 1,011

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

You are using an older version of the configuration file.  It does not work with the current version of PyTyle.  Back it up and let PyTyle create a new one.


Data is guaranteed to stay crunchy in milk.
Keep your _✍ hand strong.

Offline

#53 2009-09-09 15:15:35

x0rg
Member
From: Switzerland
Registered: 2009-07-12
Posts: 116

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Wintervenom wrote:

You are using an older version of the configuration file.  It does not work with the current version of PyTyle.  Back it up and let PyTyle create a new one.

Thanks, it works now!

Offline

#54 2009-09-13 13:27:52

ammon
Member
Registered: 2008-12-11
Posts: 413

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

How should I use this? Any manual?

and what should this mean?

pytyle                                                                                                                                ~
^C9/13/2009 at 15:27:49:    Fatal error
9/13/2009 at 15:27:49:    Traceback (most recent call last):
  File "/usr/bin/pytyle", line 173, in <module>
    e = Event()
  File "/usr/lib/python2.6/site-packages/PyTyle/Event.py", line 45, in __init__
    self._event = PROBE.get_display().next_event()
  File "/usr/lib/python2.6/site-packages/Xlib/display.py", line 178, in next_event
    return self.display.next_event()
  File "/usr/lib/python2.6/site-packages/Xlib/protocol/display.py", line 172, in next_event
    self.send_and_recv(event = 1)
  File "/usr/lib/python2.6/site-packages/Xlib/protocol/display.py", line 503, in send_and_recv
    rs, ws, es = select.select([self.socket], writeset, [], timeout)

Offline

#55 2009-09-13 14:23:32

BurntSushi
Member
From: Massachusetts
Registered: 2009-06-28
Posts: 362
Website

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

For usage, see: http://pytyle.com

As for your error... Are you sure you copied the entire error message? It looks like it may have been cut off. What were you doing when the error appeared? Which window manager are you running? Is it in a desktop environment?


Education is favorable to liberty. Freedom can exist only in a society of knowledge. Without learning, men are incapable of knowing their rights, and where learning is confined to a few people, liberty can be neither equal nor universal.

Tu ne cede malis sed contra audentior ito

Offline

#56 2009-09-13 15:22:02

ammon
Member
Registered: 2008-12-11
Posts: 413

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Ok.
I use gnome + openbox

That error must be cut-off cuz it wont report anythin otherwise.

When I try to start it it just holds, standing still on pytyle command. Tried to see help, with pytyle --help and same again.
So I kill it with ctrl+c and it writes out that error I've pased.

Offline

#57 2009-09-13 15:47:00

BurntSushi
Member
From: Massachusetts
Registered: 2009-06-28
Posts: 362
Website

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Hmm, well, did you try using PyTyle by pressing one of its commands? "Alt-A" by default will tile your windows.

Please see:

http://pytyle.com/wiki/Installation
http://pytyle.com/wiki/Configuration


Education is favorable to liberty. Freedom can exist only in a society of knowledge. Without learning, men are incapable of knowing their rights, and where learning is confined to a few people, liberty can be neither equal nor universal.

Tu ne cede malis sed contra audentior ito

Offline

#58 2009-09-13 16:51:44

ammon
Member
Registered: 2008-12-11
Posts: 413

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Ok, recompiled, added to autostart and it works. It works like a charm! Great app!! Thanks! smile

Tell me is it possible to make some app-specific rules. Like...
On my second desktop (called "net" in OB conf) is FF and pidgin (as defined in OB config). So when i start ff and pidgin OB places them on desk 2 (+ some more rules like no decor etc..) and pytyle sets them up as I like (ff as main window, pidgin left side etc), no questions asked, no alt+a needed. Just automatic, ofc defined in pytylerc.

Is there that option or could this be future request?

Offline

#59 2009-09-13 17:31:03

BurntSushi
Member
From: Massachusetts
Registered: 2009-06-28
Posts: 362
Website

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

ammon wrote:

Ok, recompiled, added to autostart and it works. It works like a charm! Great app!! Thanks! smile

Tell me is it possible to make some app-specific rules. Like...
On my second desktop (called "net" in OB conf) is FF and pidgin (as defined in OB config). So when i start ff and pidgin OB places them on desk 2 (+ some more rules like no decor etc..) and pytyle sets them up as I like (ff as main window, pidgin left side etc), no questions asked, no alt+a needed. Just automatic, ofc defined in pytylerc.

Is there that option or could this be future request?

Something like that doesn't quite exist- however, you could get close. You could enable the "global_tiling" option which will automatically tile all workspaces.

If you start Firefox first and then Pidgin, Firefox should be your main window in PyTyle. You can also alter the layout options to change the default master ratio.

But in general, no- PyTyle doesn't currently support window-specific rules for the exception of a simple filter that allows you to tell PyTyle to ignore tiling certain windows. I'm not sure if I want to go down the path of window specific rules, as other applications like devilspie accomplish this task quite eloquently. (Including removing decorations.) The closest thing I can think of is implementing some sort of feature that allows you to build layouts on the fly, but that is, off the top of my head, quite involved so it could be some time before I get to that.

You can check out all currently available options at pytyle.com


Education is favorable to liberty. Freedom can exist only in a society of knowledge. Without learning, men are incapable of knowing their rights, and where learning is confined to a few people, liberty can be neither equal nor universal.

Tu ne cede malis sed contra audentior ito

Offline

#60 2009-09-13 17:53:41

ammon
Member
Registered: 2008-12-11
Posts: 413

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Ok, it does not need to be app-specific. It could be desktop specific. Like "always tile desktop XY". But with autostart, like session. That means it will always tile that desktop, and remember user setting. Window manager will take care of the rest, like remove decoration, start app on defined desktop and so on.

And yes, on-the-fly layouts is good idea.
Keep up the good work. smile

Offline

#61 2009-09-13 19:21:10

BurntSushi
Member
From: Massachusetts
Registered: 2009-06-28
Posts: 362
Website

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

You can specify different layouts on a desktop-by-desktop basis via the configuration file. (However, you can only currently enable all desktops or none off the bat- it should be easy to implement a way to turn off/on certain workspaces. I'll add that in to the next release.)

Thanks!


Education is favorable to liberty. Freedom can exist only in a society of knowledge. Without learning, men are incapable of knowing their rights, and where learning is confined to a few people, liberty can be neither equal nor universal.

Tu ne cede malis sed contra audentior ito

Offline

#62 2009-09-16 12:41:51

ArchArael
Member
From: Switzerland
Registered: 2005-06-14
Posts: 485

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

I'm using pytyle on top of openbox and now I have the best of both worlds.

I really appreciate your work BurntSushi. Thank you dude. wink

Offline

#63 2009-09-19 18:24:12

jorpheus
Member
Registered: 2008-11-07
Posts: 98

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

I've just been toying with DWM again, and have it (somewhat) mirroring my OB setup...so I started thinking, maybe I could mirror my DWM setup in OB (and more completely than the other way around)....and five seconds later, I find this thread...heh...will be trying it out this evening.

Offline

#64 2009-09-19 18:53:14

skottish
Forum Fellow
From: Here
Registered: 2006-06-16
Posts: 7,942

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Sorry if this has been covered here, but the thread is too long now to read through every post, and when searching the thread I didn't find what I was looking for.

What if I don't want pytyle to do anything with decorations? I currently don't have window decorations in openbox and pytyle keeps turning them on. Setting decorations to the un-recommended False crashes it.

--EDIT--

I like with musca how I can resize any window that has focus in any direction available. Can I do this?

And:

you wrote:

# Note: I haven't researched this yet, but how easy is
# it to draw borders around windows (XMonad style)?

Simple if it's done at the openbox-theme level.

Offline

#65 2009-09-19 19:17:33

bernarcher
Forum Fellow
From: Germany
Registered: 2009-02-17
Posts: 2,281

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Crash confirmed on my openbox. I get this traceback when pressing Alt A with "decorations" set to False:

9/19/2009 at 21:14:35:    Could not complete key press request
9/19/2009 at 21:14:35:    Traceback (most recent call last):
  File "/usr/bin/pytyle", line 179, in <module>
    Tile.dispatch(State.get_desktop()._VIEWPORT._SCREEN.get_tiler(), None, e.get_keycode(), e.get_masks())
  File "/usr/lib/python2.6/site-packages/PyTyle/Tile.py", line 105, in dispatch
    action(tiler)
  File "/usr/lib/python2.6/site-packages/PyTyle/Tile.py", line 514, in tile
    self._tile()
  File "/usr/lib/python2.6/site-packages/PyTyle/Tilers/Vertical.py", line 72, in _tile
    self.help_resize(master, masterX, masterY, masterWidth, masterHeight)
  File "/usr/lib/python2.6/site-packages/PyTyle/Tile.py", line 421, in help_resize
    window.remove_decorations()
  File "/usr/lib/python2.6/site-packages/PyTyle/Window.py", line 269, in remove_decorations
    window.static = False
NameError: global name 'window' is not defined

To know or not to know ...
... the questions remain forever.

Offline

#66 2009-09-19 20:35:52

jorpheus
Member
Registered: 2008-11-07
Posts: 98

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Using OB, stuff so far:

1. Hints. I'd prefer true maximize (like OB does). I think I've read smth about it on this thread, I'll go back and re-read now.
2. PyTyle ignores my 1 pixel on each side setting, but I fixed this in its conf file.
3. Terminology - you use "workspace", "screen" and "desktop" - and it's ambiguous in some cases. Which leads me to...
4. Sending a window to a different "screen" - is "screen" here "workspace" or is it screen (in the sense of X)? If it's the first, it's not working.
5. When starting, why not enable tiling across all workspaces? It's a drag to do it manually for each - and I have only four.
6. Related to 5) and 4), assuming first case in 4), why only suport three workspaces?

I really like this, btw smile

Edit:

OK, scratch 5), it's there.

Last edited by jorpheus (2009-09-19 20:44:50)

Offline

#67 2009-09-19 20:38:30

jorpheus
Member
Registered: 2008-11-07
Posts: 98

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

skottish wrote:

What if I don't want pytyle to do anything with decorations? I currently don't have window decorations in openbox and pytyle keeps turning them on. Setting decorations to the un-recommended False crashes it.

I don't have them in OB either, no conflict with PT (I just left the default True) - they're off.

Offline

#68 2009-09-19 20:59:04

skottish
Forum Fellow
From: Here
Registered: 2006-06-16
Posts: 7,942

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

jorpheus wrote:
skottish wrote:

What if I don't want pytyle to do anything with decorations? I currently don't have window decorations in openbox and pytyle keeps turning them on. Setting decorations to the un-recommended False crashes it.

I don't have them in OB either, no conflict with PT (I just left the default True) - they're off.

Even if you toggle between tiling and floating? When I start up, they're off. When I go to tiling, they stay off. When I toggle back, they're turned on until I close and restart whatever app.

Offline

#69 2009-09-19 21:02:24

Wintervenom
Member
From: /home/wintervenom
Registered: 2008-08-20
Posts: 1,011

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

When I turn them off in the Openbox config, PyTyle still reserves space for them.


Data is guaranteed to stay crunchy in milk.
Keep your _✍ hand strong.

Offline

#70 2009-09-19 21:09:47

skottish
Forum Fellow
From: Here
Registered: 2006-06-16
Posts: 7,942

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

Wintervenom wrote:

When I turn them off in the Openbox config, PyTyle still reserves space for them.

That explains why Pytyle "loses" more space than the tiling WMs do. musca leaves some gaps with apps like urxvt and gvim, but no where near as pronounced as Pytyle.

Offline

#71 2009-09-19 22:18:54

jorpheus
Member
Registered: 2008-11-07
Posts: 98

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

skottish wrote:

Even if you toggle between tiling and floating? When I start up, they're off. When I go to tiling, they stay off. When I toggle back, they're turned on until I close and restart whatever app.

You're right, they appear after untiling.

Offline

#72 2009-09-19 23:04:30

BurntSushi
Member
From: Massachusetts
Registered: 2009-06-28
Posts: 362
Website

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

skottish wrote:

What if I don't want pytyle to do anything with decorations? I currently don't have window decorations in openbox and pytyle keeps turning them on. Setting decorations to the un-recommended False crashes it.

Ah, okay- I had never considered starting with no decorations.

So the problem here is that Openbox doesn't accurately report whether there's a decoration on a window or not. It will simply report the size of such a decoration- even if it isn't present. That explains why PyTyle was reserving space for decorations if you disable them from the Openbox end.

Because of this, PyTyle really can't know if there are decorations or not. So my solution was to add an additional MISC configuration option: original_decor.

In your case, set decorations and original_decor to false. (And I've fixed the bug causing PyTyle to crash when disabling decorations.)

I've updated the wiki: Original Decorations.

skottish wrote:

I like with musca how I can resize any window that has focus in any direction available. Can I do this?

Not quite. Resize directions change with each layout (i.e., Vertical vs. Horizontal), but you cannot resize any window in an arbitrary direction.

I think I had originally tried this, and had put it on the back burner because it was slightly more complex than I at first thought. However, now that I think about it, I should be able to pull algorithm for resizing in HorizontalRows.

I'll post an update when I get to that.

skottish wrote:
you wrote:

# Note: I haven't researched this yet, but how easy is
# it to draw borders around windows (XMonad style)?

Simple if it's done at the openbox-theme level.

Yeah, the main drawback to that is it's only for Openbox. Considering one can only remove decorations in Openbox using PyTyle, this would seem okay.

I've also found some code in PLWM that draws a simple border around a window using Xlib. I'll see what I can do to adapt that.

jorpheus wrote:

1. Hints. I'd prefer true maximize (like OB does). I think I've read smth about it on this thread, I'll go back and re-read now.

Yeah, I actually prefer that as well. I tried implementing it, and now I can only remember that I hit some problems with it. I'll revisit it and see if I can cook up a solution.

jorpheus wrote:

2. PyTyle ignores my 1 pixel on each side setting, but I fixed this in its conf file.

Hmm, I'm not sure what you mean by this. Oh, are you referring to Openbox margins? I'm assuming you fixed it using the workarea in the PyTyle config.

If so, that's the right thing to do.

jorpheus wrote:

3. Terminology - you use "workspace", "screen" and "desktop" - and it's ambiguous in some cases. Which leads me to...
4. Sending a window to a different "screen" - is "screen" here "workspace" or is it screen (in the sense of X)? If it's the first, it's not working.
6. Related to 5) and 4), assuming first case in 4), why only suport three workspaces?

Yeah, admittedly, my terminology is poor. Where I used "screen" I should probably use "logical screen" or "physical screen" or "head" or "monitor." Separate screens traditionally imply separate X sessions (which isn't how I'm using the term). PyTyle is specifically built for Xinerama.

The short of it is this: PyTyle allows you to move windows to other monitors and preserve tiling state. There really isn't an accepted way of moving windows from one monitor to the next, so that's why you're seeing the ability to do it in PyTyle. (Openbox will allow you to move a window to another monitor using a key binding, though. Which can still be used with PyTyle.) As far as workspaces go- just about all window managers provide some key binding to move a window to another workspace (or a pager/panel will do this), and that works fine with PyTyle. Very few window managers provide the ability to switch focus to another screen. You can do this traditionally using Alt-Tab, but that's switching focus in a window-oriented way, rather than a monitor-oriented way. (XMonad will allow you to switch focus between screens.) So PyTyle also allows you to do that as well.

I'm not sure why I'm still using the word "screen," but I did comment on it here: http://pytyle.com/wiki/Configuration#Terminology

jorpheus wrote:

I really like this, btw smile

Great, thanks for the feedback! big_smile

skottish wrote:
Wintervenom wrote:

When I turn them off in the Openbox config, PyTyle still reserves space for them.

That explains why Pytyle "loses" more space than the tiling WMs do. musca leaves some gaps with apps like urxvt and gvim, but no where near as pronounced as Pytyle.

Almost.

Certainly, if you disable decorations in Openbox, the extra space between windows is because PyTyle is still reserving that space. (Openbox is still reporting the existence of decorations.)

As far as urxvt and gvim go, this was a huge thorn in my side. So much so that I switched to mrxvt. I actually wrote a lengthy post in this topic: #44. (Sorry, don't know how to link to individual posts in FluxBB.)

More specifically, Tiling WM's have the ability to ignore application's requests for resize increments. This prevents any gaps.


Oh, I've actually tried PyTyle on KWin as well. It actually seems to be working. (Kudos to the KDE dev team for making a EWMH compliant WM!) If you have desktop effects (like wobbly windows) enabled, though, it looks a bit mucky.

I tried it after seeing kwin-tiling.


AUR has been updated. CHANGELOG:

0.7.4

- Bug fix: Detection of panel orientation
    If you let PyTyle automatically detect your panels (i.e., not setting your
    workarea), then it wasn't properly reserving space if your panel was at
    the top or left of your screen.
   
- Bug fix: Decorations (NEW CONFIGURATION OPTION ADDED)
    If you aren't using any decorations at all in Openbox, then PyTyle was still
    fiddling with them. Specifically, if you had decorations disabled on the
    Openbox end, then PyTyle would re-add them if you issued an untile command.
   
    Since Openbox still reports the sizes of decorations even when they're
    disabled, there really isn't a way to reliably detect whether a window has
    decorations or not. The solution here was to add a new configuration option:
    original_decor. This should simply be whether or not you have decorations
    enabled/disabled from the Openbox end.


Education is favorable to liberty. Freedom can exist only in a society of knowledge. Without learning, men are incapable of knowing their rights, and where learning is confined to a few people, liberty can be neither equal nor universal.

Tu ne cede malis sed contra audentior ito

Offline

#73 2009-09-19 23:36:58

skottish
Forum Fellow
From: Here
Registered: 2006-06-16
Posts: 7,942

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

BurntSushi,

That's sweet. It's definitely better with this newest revision. Sure, between just urxvtc and gvim, the gap is still fairly pronounced, but with two instances of urxvtc and gvim, it's as good as I've seen with any of the tilers.

I'll tell you what, I'm very close to having the setup that I've been working towards for weeks. I've had more window managers installed on this system lately than I care to think about. The only thing that I'd love to have was already mentioned: the ability to resize windows arbitrarily. I'm wondering if some of the musca code could easily be ported over.

By the way, I have well over 5000 posts and I don't know how to link to specific post either!

Thank you so much for this. You may be ending my quest for the perfect setup.


***** EDIT *****

That's with Firefox open as the master in the last two examples.

***** EDIT 2 *****

One of the things that you've done better than anything that I've seen is when toggling back and forth between floating and tiling that you handle the original size of every window properly. This is a big deal for me and it's working excellently.

Offline

#74 2009-09-19 23:55:32

BurntSushi
Member
From: Massachusetts
Registered: 2009-06-28
Posts: 362
Website

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

skottish wrote:

BurntSushi,

That's sweet. It's definitely better with this newest revision. Sure, between just urxvtc and gvim, the gap is still fairly pronounced, but with two instances of urxvtc and gvim, it's as good as I've seen with any of the tilers.

Strange. Does XMonad exhibit that behavior too? I mean, I know it's the window manager's job to listen to those resize increments, so those tiling window managers are purposefully putting those gaps there. (As opposed to just tiling managers- we don't have a choice!)

skottish wrote:

I'll tell you what, I'm very close to having the setup that I've been working towards for weeks. I've had more window managers installed on this system lately than I care to think about.

That's really great to hear. I'm still struggling with the perfect setup as well.

My main problem is that I use multiple monitors. And quite honestly, multiple monitor support sucks, in general, on Linux. In the last week, I've hacked together my own panel, as no panel gets multi monitor support correct. (Gnome-panel and Tint2 are the closest. I actually haven't tried Kicker yet.) It's still quite buggy, but suits my purposes currently, as I can hack up the code quickly. It's essentially PyPanel on steroids with menus.

I've actually been looking into building my own Gtk based window manager- such that Xinerama isn't an afterthought. I was prototyping today, and it seems I've underestimated the task. I've pushed it off to perhaps the end of this semester. (For instance, XMonad's greedy view in a floating WM- where is it? Or how about not letting the mouse wander off into dead regions. Or getting the partial struts implemented correctly. Window movement/focus between screens. The list goes on...) I also want to investigate composite possibilities in a tiling environment- there doesn't seem to be any of these around yet.

skottish wrote:

The only thing that I'd love to have was already mentioned: the ability to resize windows arbitrarily. I'm wondering if some of the musca code could easily be ported over.

Yeah, I've been meaning to give Musca a try. Just haven't had the time yet. I've heard some really good things about it. (I think I was being dramatic; the algorithm isn't that bad. Haha.)

Actually, now that I think about it, I think my problem was with the urxvt/gvim thing. Before I had found out about the resize increment hints, I was testing the sizing of windows arbitrarily with them, and everything started going haywire. I should be able to work with it now, though.

skottish wrote:

By the way, I have well over 5000 posts and I don't know how to link to specific post either!

Yeah, in another life I was a message board developer. I tried a few common tricks with the URLs, but nothing worked. sad

skottish wrote:

Thank you so much for this. You may be ending my quest for the perfect setup.

I hope I can say the same for me in due time! Getting multi-monitors working properly is really hard.


*EDIT*

skottish wrote:

One of the things that you've done better than anything that I've seen is when toggling back and forth between floating and tiling that you handle the original size of every window properly. This is a big deal for me and it's working excellently.

Yeah, I'm not sure why it's been skipped over. There was one trick: finding the original position of the window. (Size is easy.) When using Xlib, the straight-forward way of fetching a window's geometry gives back coordinates relative to the root window (i.e., no good). You actually need to translate these coordinates before they become usable.

Throw in viewports with Compiz- yuck. Positioning is then relative to whichever viewport you're on.

Last edited by BurntSushi (2009-09-19 23:57:56)


Education is favorable to liberty. Freedom can exist only in a society of knowledge. Without learning, men are incapable of knowing their rights, and where learning is confined to a few people, liberty can be neither equal nor universal.

Tu ne cede malis sed contra audentior ito

Offline

#75 2009-09-20 19:31:49

jorpheus
Member
Registered: 2008-11-07
Posts: 98

Re: PyTyle: Manual tiling manager for EWMH compliant WM's

BurntSushi wrote:

Yeah, I actually prefer that as well. I tried implementing it, and now I can only remember that I hit some problems with it. I'll revisit it and see if I can cook up a solution.

Cool smile I mean, I could (and I did) use OB to maximize all windows - but then I get every dialog ever maxed, which is less than desirable.

BurntSushi wrote:

Hmm, I'm not sure what you mean by this. Oh, are you referring to Openbox margins? I'm assuming you fixed it using the workarea in the PyTyle config.

Did so. And I do understand you'd like to make this WM agnostic as possible, since not everyone uses OB.

BurntSushi wrote:

The short of it is this: PyTyle allows you to move windows to other monitors and preserve tiling state. There really isn't an accepted way of moving windows from one monitor to the next, so that's why you're seeing the ability to do it in PyTyle. (Openbox will allow you to move a window to another monitor using a key binding, though. Which can still be used with PyTyle.) As far as workspaces go- just about all window managers provide some key binding to move a window to another workspace (or a pager/panel will do this), and that works fine with PyTyle. Very few window managers provide the ability to switch focus to another screen. You can do this traditionally using Alt-Tab, but that's switching focus in a window-oriented way, rather than a monitor-oriented way. (XMonad will allow you to switch focus between screens.) So PyTyle also allows you to do that as well.

Okay, I thought you used 'screen' in the first sense, but then there's this: there is screen_focus and screen_put - and if screen_put is moving the window to another workspace, it doesn't work (for me) - of course, I have this configured in OB and that works just fine, so I just commented out those lines, so this is either clarification for future reference or a bug report.

Offline

Board footer

Powered by FluxBB