PyTyle: Manual tiling manager for EWMH compliant WM's

BurntSushi · 2011-08-04 15:09:26

GSF1200S wrote:

I went crazy over the wasted pixels even though its not Pytyles fault. I prefer having a terminal with right-click options, etc, so I thought id post that Terminator has a "Window Geometry hints" option under the global tab of its preferences. Unchecking that box allows it to work perfect with no wasted pixels under pytyle/openbox. I should mention that terminator is capable of splitting, tabbing, etc which is kind of cool considering its a form of tiling itself..
Just in case anyone wanted to know..

Thanks for the tip!

Since my last post on the topic, I've learned a few other things...

Firstly, Konsole will also cooperate; it does not set any resize increment hints. (It is my terminal of choice.)

Secondly, hacking Openbox isn't necessarily enough (I've tried). The easiest way around this issue is to adjust the urxvt (or whichever terminal) source code so that it doesn't set this hint. I believe such an adjustment can be found in the AUR here or here. Even if you force Openbox to not honor the resize hints, it seems some of the applications (perhaps it's GTK itself) breaks with standards and enforces them anyway. There are more ways around this, but it becomes increasingly complex.

If someone has some other terminal they'd like to use and it isn't cooperating, I'd be happy to take a crack at it. The modification shouldn't be anything more than removing a line or two.

GSF1200S · 2011-08-04 23:03:47

BurntSushi wrote:

GSF1200S wrote:
I went crazy over the wasted pixels even though its not Pytyles fault. I prefer having a terminal with right-click options, etc, so I thought id post that Terminator has a "Window Geometry hints" option under the global tab of its preferences. Unchecking that box allows it to work perfect with no wasted pixels under pytyle/openbox. I should mention that terminator is capable of splitting, tabbing, etc which is kind of cool considering its a form of tiling itself..
Just in case anyone wanted to know..
Thanks for the tip!
Since my last post on the topic, I've learned a few other things...
Firstly, Konsole will also cooperate; it does not set any resize increment hints. (It is my terminal of choice.)
Secondly, hacking Openbox isn't necessarily enough (I've tried). The easiest way around this issue is to adjust the urxvt (or whichever terminal) source code so that it doesn't set this hint. I believe such an adjustment can be found in the AUR here or here. Even if you force Openbox to not honor the resize hints, it seems some of the applications (perhaps it's GTK itself) breaks with standards and enforces them anyway. There are more ways around this, but it becomes increasingly complex.
If someone has some other terminal they'd like to use and it isn't cooperating, I'd be happy to take a crack at it. The modification shouldn't be anything more than removing a line or two.

Might you tell us approximately what we are looking for in terms of the lines to edit/remove? I prefer using XFCE terminal instead of Terminator in most situations (Terminator is slow to open), and im sure I could modify the source myself and cook up my own pkgbuild for it. At this point (having found Terminator), this isnt urgent or anything, but maybe posting it here would aid others in being able to edit their terminal's source?

I say this because, before I found pytyle, I used XFCE and compiz. Once I discovered pytyle (and its issues with compiz due to compiz using viewports instead of workspaces), I completely wiped my Arch install to start anew with a system designed specifically around openbox and pytyle (and I love XFCE/Compiz, so..). This program has greatly increased my productivity in many ways, and I have seen other posts in other forums saying the same thing- it would be cool if someone had a general idea of what kind of lines to look for and roughly what they need to accomplish to get all the space possible out of each tile.

Btw, Im using pytyle 1 instead of pytyle 2, so keep that in mind. Pytyle2 will not work on my new Arch install- not sure if im doing something wrong though.. pytyle 1 works great. Just to let you know..

**EDIT** Another reason I ask/suggest this is because it isnt exactly right to expect you to figure out how to make each terminal ignore window resize hints directly; thats quite a bit to ask, especially when these terminals will constantly be upgraded. I might in the future throw up some pkgbuilds on the AUR that are like "terminal-nohints" etc to make it easier for people to stay up to date without having to constantly patch/modify the sources themselves (gotta get through my calculus final first!)..

Last edited by GSF1200S (2011-08-04 23:08:19)

BurntSushi · 2011-08-05 00:15:26

Ah, good idea :-)

The key is to look for where the application sets the WM_NORMAL_HINTS (sometimes called the window geometry hints). They are typically only set once when the application creates its main window, and then it's done with it. (The GUI kit being used will take care of the rest.)

Two of the hints in WM_NORMAL_HINTS are the 'width_inc' and 'height_inc' hints. (See the ICCCM docs.) These tell the window manager to do precisely what you'd think; only allow the window to change size in a specified number of pixels. In the typical case of a terminal, these correspond to a character's width and height.

When hacking a terminal to get rid of this behavior, the easiest way is to simply change the 'width_inc' and 'height_inc' hints to '1'. If you're lucky, a quick grep of 'width_inc', 'hint', or even 'width' should narrow down where you need to look fairly quickly.

Here's a patch for XFCE Terminal:

diff --git a/terminal/terminal-screen.c b/terminal/terminal-screen.c
index 0c0217a..56557d2 100644
--- a/terminal/terminal-screen.c
+++ b/terminal/terminal-screen.c
@@ -1551,8 +1551,8 @@ terminal_screen_set_window_geometry_hints (TerminalScreen *screen,
 
   hints.base_width = xpad;
   hints.base_height = ypad;
-  hints.width_inc = VTE_TERMINAL (screen->terminal)->char_width ;
-  hints.height_inc = VTE_TERMINAL (screen->terminal)->char_height;
+  hints.width_inc = 1;
+  hints.height_inc = 1;
   hints.min_width = hints.base_width + hints.width_inc * 4;
   hints.min_height = hints.base_height + hints.height_inc * 2;

Oddly, I couldn't get XFCE Terminal to compile (even after emulating the official Arch PKGBUILD). The change is small enough though, that I'm fairly confident it should be good.

I think the change is so small that if you throw up a patch against a repository, it will probably last for a good long while.

Finally, you can verify that your code changed something by using xprop. Execute `xprop WM_NORMAL_HINTS` at the command line; your cursor should turn into crosshairs. Then click on an XFCE Terminal window and examine the output. You should see that the width and height resize increments are set to 1.

GSF1200S wrote:

(gotta get through my calculus final first!)

Ah good luck, I enjoyed my Calculus classes :-)

Last edited by BurntSushi (2011-08-05 00:16:12)

GSF1200S · 2011-08-09 09:10:31

BurntSushi wrote:

Ah, good idea :-)
The key is to look for where the application sets the WM_NORMAL_HINTS (sometimes called the window geometry hints). They are typically only set once when the application creates its main window, and then it's done with it. (The GUI kit being used will take care of the rest.)
Two of the hints in WM_NORMAL_HINTS are the 'width_inc' and 'height_inc' hints. (See the ICCCM docs.) These tell the window manager to do precisely what you'd think; only allow the window to change size in a specified number of pixels. In the typical case of a terminal, these correspond to a character's width and height.
When hacking a terminal to get rid of this behavior, the easiest way is to simply change the 'width_inc' and 'height_inc' hints to '1'. If you're lucky, a quick grep of 'width_inc', 'hint', or even 'width' should narrow down where you need to look fairly quickly.
Here's a patch for XFCE Terminal:
diff --git a/terminal/terminal-screen.c b/terminal/terminal-screen.c
index 0c0217a..56557d2 100644
--- a/terminal/terminal-screen.c
+++ b/terminal/terminal-screen.c
@@ -1551,8 +1551,8 @@ terminal_screen_set_window_geometry_hints (TerminalScreen *screen,
 
   hints.base_width = xpad;
   hints.base_height = ypad;
-  hints.width_inc = VTE_TERMINAL (screen->terminal)->char_width ;
-  hints.height_inc = VTE_TERMINAL (screen->terminal)->char_height;
+  hints.width_inc = 1;
+  hints.height_inc = 1;
   hints.min_width = hints.base_width + hints.width_inc * 4;
   hints.min_height = hints.base_height + hints.height_inc * 2;
Oddly, I couldn't get XFCE Terminal to compile (even after emulating the official Arch PKGBUILD). The change is small enough though, that I'm fairly confident it should be good.
I think the change is so small that if you throw up a patch against a repository, it will probably last for a good long while.
Finally, you can verify that your code changed something by using xprop. Execute `xprop WM_NORMAL_HINTS` at the command line; your cursor should turn into crosshairs. Then click on an XFCE Terminal window and examine the output. You should see that the width and height resize increments are set to 1.
GSF1200S wrote:
(gotta get through my calculus final first!)
Ah good luck, I enjoyed my Calculus classes :-)

Sorry for the delay- had to finish out that final and avoid getting roped into stuff like this as much as possible

Thanks for the patch; it works.. kinda. The terminal leaves no wasted pixels (when pytyle is invoked), however when I open it (in floating mode), its very very small. I have to resize it from literally just a title bar to a normal sized window (when pytyle is not invoked). This happens every time I open it- terminator doesnt have this problem, and there is no wasted pixels, so there must be a way..

I will take a look at the source where you made your changes tomorrow and see if I can figure it out. I might actually try instead on lxterminal which is just as good for me and see if that helps. Regardless, your patch and everything should get me started in the right direction..

Thanks again for pytyle and for all the help

BurntSushi · 2011-08-09 15:44:51

GSF1200S wrote:

Sorry for the delay- had to finish out that final and avoid getting roped into stuff like this as much as possible

Been there, done that :-) Sometimes hacking wins out though!

GSF1200S wrote:

Thanks for the patch; it works.. kinda. The terminal leaves no wasted pixels (when pytyle is invoked), however when I open it (in floating mode), its very very small. I have to resize it from literally just a title bar to a normal sized window (when pytyle is not invoked). This happens every time I open it- terminator doesnt have this problem, and there is no wasted pixels, so there must be a way..

Damn. That's really weird. Changing the width/height increment shouldn't affect the initial size that much.

I spent about 30 minutes looking at xfce-terminal, and this is the best I can come up with:

hints.base_width = xpad;
  hints.base_height = ypad;
  hints.width_inc = 1;
  hints.height_inc = 1;
  hints.min_width = hints.base_width + hints.width_inc * 4;
  hints.min_height = hints.base_height + hints.height_inc * 2;

  gtk_window_set_geometry_hints (GTK_WINDOW (window),
                                 screen->terminal,
                                 &hints,
                                 GDK_HINT_RESIZE_INC
                                 | GDK_HINT_MIN_SIZE
                                 | GDK_HINT_BASE_SIZE);

  gtk_window_set_default_size (GTK_WINDOW (window), 500, 200);

The only change is the last last "gtk_window_set...". I still can't compile the damn thing, even with ABS so I have no idea if that will work. I have very little experience with GTK, but these functions seem like they correspond fairly well to their X counterparts.

GSF1200S wrote:

I will take a look at the source where you made your changes tomorrow and see if I can figure it out. I might actually try instead on lxterminal which is just as good for me and see if that helps. Regardless, your patch and everything should get me started in the right direction..

I was using lxterminal a few months ago, so I have a patch that I know works :-)

diff --git a/src/lxterminal.c b/src/lxterminal.c
index da232b1..a848073 100644
--- a/src/lxterminal.c
+++ b/src/lxterminal.c
@@ -632,8 +632,8 @@ static gboolean terminal_window_size_request_event(GtkWidget * widget, GtkRequis
         Term * term = g_ptr_array_index(terminal->terms, 0);
         GtkBorder * border = terminal_get_border(term);
         GdkGeometry hints;
-        hints.width_inc = vte_terminal_get_char_width(VTE_TERMINAL(term->vte));  
-        hints.height_inc = vte_terminal_get_char_height(VTE_TERMINAL(term->vte));
+        hints.width_inc = 1;
+        hints.height_inc = 1;
         hints.base_width = border->left;
         hints.base_height = border->top;
         hints.min_width = hints.base_width + hints.width_inc * 4;

GSF1200S wrote:

Thanks again for pytyle and for all the help

No problem! My pleasure.

GSF1200S · 2011-08-09 22:26:10

BurntSushi wrote:

GSF1200S wrote:
Sorry for the delay- had to finish out that final and avoid getting roped into stuff like this as much as possible
Been there, done that :-) Sometimes hacking wins out though!
GSF1200S wrote:
Thanks for the patch; it works.. kinda. The terminal leaves no wasted pixels (when pytyle is invoked), however when I open it (in floating mode), its very very small. I have to resize it from literally just a title bar to a normal sized window (when pytyle is not invoked). This happens every time I open it- terminator doesnt have this problem, and there is no wasted pixels, so there must be a way..
Damn. That's really weird. Changing the width/height increment shouldn't affect the initial size that much.
I spent about 30 minutes looking at xfce-terminal, and this is the best I can come up with:
hints.base_width = xpad;
  hints.base_height = ypad;
  hints.width_inc = 1;
  hints.height_inc = 1;
  hints.min_width = hints.base_width + hints.width_inc * 4;
  hints.min_height = hints.base_height + hints.height_inc * 2;

  gtk_window_set_geometry_hints (GTK_WINDOW (window),
                                 screen->terminal,
                                 &hints,
                                 GDK_HINT_RESIZE_INC
                                 | GDK_HINT_MIN_SIZE
                                 | GDK_HINT_BASE_SIZE);

  gtk_window_set_default_size (GTK_WINDOW (window), 500, 200);
The only change is the last last "gtk_window_set...". I still can't compile the damn thing, even with ABS so I have no idea if that will work. I have very little experience with GTK, but these functions seem like they correspond fairly well to their X counterparts.
GSF1200S wrote:
I will take a look at the source where you made your changes tomorrow and see if I can figure it out. I might actually try instead on lxterminal which is just as good for me and see if that helps. Regardless, your patch and everything should get me started in the right direction..
I was using lxterminal a few months ago, so I have a patch that I know works :-)
diff --git a/src/lxterminal.c b/src/lxterminal.c
index da232b1..a848073 100644
--- a/src/lxterminal.c
+++ b/src/lxterminal.c
@@ -632,8 +632,8 @@ static gboolean terminal_window_size_request_event(GtkWidget * widget, GtkRequis
         Term * term = g_ptr_array_index(terminal->terms, 0);
         GtkBorder * border = terminal_get_border(term);
         GdkGeometry hints;
-        hints.width_inc = vte_terminal_get_char_width(VTE_TERMINAL(term->vte));  
-        hints.height_inc = vte_terminal_get_char_height(VTE_TERMINAL(term->vte));
+        hints.width_inc = 1;
+        hints.height_inc = 1;
         hints.base_width = border->left;
         hints.base_height = border->top;
         hints.min_width = hints.base_width + hints.width_inc * 4;
GSF1200S wrote:
Thanks again for pytyle and for all the help
No problem! My pleasure.

Haha, the xfce-terminal built no problem, but for some reason I still get the mini terminal that I must resize; ill figure it out once I tackle the source there- its got to be impossible when you cant even build it, so dont worry about it. Quickly tried the lxterminal patch, and I keep getting:

  -> Found lxtermfix.patch
==> Validating source files with md5sums...
    lxterminal-0.1.11.tar.gz ... Passed
    lxtermfix.patch ... Passed
==> Extracting Sources...
  -> Extracting lxterminal-0.1.11.tar.gz with bsdtar
==> Starting build()...
patching file src/lxterminal.c
Hunk #1 FAILED at 632.
1 out of 1 hunk FAILED -- saving rejects to file src/lxterminal.c.rej
==> ERROR: A failure occurred in build().
    Aborting...

Since im new to patching, I checked the source and noted that the lines mentioned here actually start on line 655 instead of 632 (if that is indeed what the number represents). I tried changing 632 to 655, but no luck. Im about to try unpacking the source, editing the lxterminal.c file directly with your changes, retarring, changing the pkgbuild source to $srcdir, then try building again..

Haha, this is why I stayed away before I finished that exam- indeed hacking wins out sometimes.. Once I get these all figured out, I think im gonna throw up some AUR pkgbuilds named "lxterminal-pytyle" and "terminal-pytyle" if thats cool with you..

BurntSushi · 2011-08-09 23:01:51

GSF1200S wrote:

Haha, the xfce-terminal built no problem, but for some reason I still get the mini terminal that I must resize; ill figure it out once I tackle the source there- its got to be impossible when you cant even build it, so dont worry about it.

Yeah, it's really frustrating. I bet I could get it working if I could build it. Using the official Arch PKGBUILD, all I get is:

  CC     Terminal-terminal-app.o
In file included from terminal-app.c:36:0:
/usr/include/string.h:455:13: error: expected declaration specifiers or ‘...’ before ‘(’ token
/usr/include/string.h:455:13: error: expected declaration specifiers or ‘...’ before ‘(’ token
/usr/include/string.h:455:13: error: expected declaration specifiers or ‘...’ before ‘(’ token
make[3]: *** [Terminal-terminal-app.o] Error 1

Which is the same error I get if I compile it by hand (and for the git version). Experience tells me I've done something very stupid or there is something I changed in my environment that I should have changed back.

GSF1200S wrote:

Quickly tried the lxterminal patch, and I keep getting:
  -> Found lxtermfix.patch
==> Validating source files with md5sums...
    lxterminal-0.1.11.tar.gz ... Passed
    lxtermfix.patch ... Passed
==> Extracting Sources...
  -> Extracting lxterminal-0.1.11.tar.gz with bsdtar
==> Starting build()...
patching file src/lxterminal.c
Hunk #1 FAILED at 632.
1 out of 1 hunk FAILED -- saving rejects to file src/lxterminal.c.rej
==> ERROR: A failure occurred in build().
    Aborting...
Since im new to patching, I checked the source and noted that the lines mentioned here actually start on line 655 instead of 632 (if that is indeed what the number represents). I tried changing 632 to 655, but no luck. Im about to try unpacking the source, editing the lxterminal.c file directly with your changes, retarring, changing the pkgbuild source to $srcdir, then try building again..

I'm an idiot. I forgot to merge the most up to date version of lxterminal with my branch. Here's a revised patch:

diff --git a/src/lxterminal.c b/src/lxterminal.c
index 5d4940f..0ce5d5f 100644
--- a/src/lxterminal.c
+++ b/src/lxterminal.c
@@ -655,8 +655,8 @@ static gboolean terminal_window_size_request_event(GtkWidget * widget, G
         Term * term = g_ptr_array_index(terminal->terms, 0);
         GtkBorder * border = terminal_get_border(term);
         GdkGeometry hints;
-        hints.width_inc = vte_terminal_get_char_width(VTE_TERMINAL(term->vte));  
-        hints.height_inc = vte_terminal_get_char_height(VTE_TERMINAL(term->vte));
+        hints.width_inc = 1;
+        hints.height_inc = 1;
         hints.base_width = border->right + 1;
         hints.base_height = border->bottom + 1;
         hints.min_width = hints.base_width + hints.width_inc * 4;

Sorry about that. This patch is against their git repo though.

I do have a suggestion though; use a sane name for your patch file if you throw it up on AUR. Something like lxterminal-remove-resize-increments.patch. That way you'll remember what the hell it was you fixed a year from now :-)

GSF1200S wrote:

Haha, this is why I stayed away before I finished that exam

Very wise!

GSF1200S wrote:

Once I get these all figured out, I think im gonna throw up some AUR pkgbuilds named "lxterminal-pytyle" and "terminal-pytyle" if thats cool with you..

Of course. I'm not sure what the protocol typically is, but it might be easier to apply patches on the corresponding git packages. Up to you.

In keeping with name suggestions, I don't know if "*-pytyle" is appropriate. There are a few other tiling programs out there that might also benefit from this kind of modification. Maybe "*-no-resize-inc" or something? *shrug* On the other hand, most people don't know that "resize increments" are the problem anyway. They usually blame pytyle

GSF1200S · 2011-08-11 07:28:15

BurntSushi wrote:

GSF1200S wrote:
Haha, the xfce-terminal built no problem, but for some reason I still get the mini terminal that I must resize; ill figure it out once I tackle the source there- its got to be impossible when you cant even build it, so dont worry about it.
Yeah, it's really frustrating. I bet I could get it working if I could build it. Using the official Arch PKGBUILD, all I get is:
  CC     Terminal-terminal-app.o
In file included from terminal-app.c:36:0:
/usr/include/string.h:455:13: error: expected declaration specifiers or ‘...’ before ‘(’ token
/usr/include/string.h:455:13: error: expected declaration specifiers or ‘...’ before ‘(’ token
/usr/include/string.h:455:13: error: expected declaration specifiers or ‘...’ before ‘(’ token
make[3]: *** [Terminal-terminal-app.o] Error 1
Which is the same error I get if I compile it by hand (and for the git version). Experience tells me I've done something very stupid or there is something I changed in my environment that I should have changed back.
GSF1200S wrote:
Quickly tried the lxterminal patch, and I keep getting:
  -> Found lxtermfix.patch
==> Validating source files with md5sums...
    lxterminal-0.1.11.tar.gz ... Passed
    lxtermfix.patch ... Passed
==> Extracting Sources...
  -> Extracting lxterminal-0.1.11.tar.gz with bsdtar
==> Starting build()...
patching file src/lxterminal.c
Hunk #1 FAILED at 632.
1 out of 1 hunk FAILED -- saving rejects to file src/lxterminal.c.rej
==> ERROR: A failure occurred in build().
    Aborting...
Since im new to patching, I checked the source and noted that the lines mentioned here actually start on line 655 instead of 632 (if that is indeed what the number represents). I tried changing 632 to 655, but no luck. Im about to try unpacking the source, editing the lxterminal.c file directly with your changes, retarring, changing the pkgbuild source to $srcdir, then try building again..
I'm an idiot. I forgot to merge the most up to date version of lxterminal with my branch. Here's a revised patch:
diff --git a/src/lxterminal.c b/src/lxterminal.c
index 5d4940f..0ce5d5f 100644
--- a/src/lxterminal.c
+++ b/src/lxterminal.c
@@ -655,8 +655,8 @@ static gboolean terminal_window_size_request_event(GtkWidget * widget, G
         Term * term = g_ptr_array_index(terminal->terms, 0);
         GtkBorder * border = terminal_get_border(term);
         GdkGeometry hints;
-        hints.width_inc = vte_terminal_get_char_width(VTE_TERMINAL(term->vte));  
-        hints.height_inc = vte_terminal_get_char_height(VTE_TERMINAL(term->vte));
+        hints.width_inc = 1;
+        hints.height_inc = 1;
         hints.base_width = border->right + 1;
         hints.base_height = border->bottom + 1;
         hints.min_width = hints.base_width + hints.width_inc * 4;
Sorry about that. This patch is against their git repo though.
I do have a suggestion though; use a sane name for your patch file if you throw it up on AUR. Something like lxterminal-remove-resize-increments.patch. That way you'll remember what the hell it was you fixed a year from now :-)
GSF1200S wrote:
Haha, this is why I stayed away before I finished that exam
Very wise!
GSF1200S wrote:
Once I get these all figured out, I think im gonna throw up some AUR pkgbuilds named "lxterminal-pytyle" and "terminal-pytyle" if thats cool with you..
Of course. I'm not sure what the protocol typically is, but it might be easier to apply patches on the corresponding git packages. Up to you.
In keeping with name suggestions, I don't know if "*-pytyle" is appropriate. There are a few other tiling programs out there that might also benefit from this kind of modification. Maybe "*-no-resize-inc" or something? *shrug* On the other hand, most people don't know that "resize increments" are the problem anyway. They usually blame pytyle

Cheers, the lxterminal patch went through without a hitch. Im still working on the xfce-terminal patch- Im gonna see if I cant get a hold of a dev and see if he/she knows how I would accomplish an initial window size. I think im going to just use git pkgbuilds and patch against that for no resize hints.

Thanks for the help..

ColInvictus · 2011-11-05 03:25:53

Hi

I've just tried to run PyTyle2 for the first time and encountered this error:

Traceback (most recent call last):
  File "/usr/local/bin/pytyle2", line 25, in <module>
    import pt.config as config
ImportError: No module named config

I'm using Openbox, if that's any use. It works if I run it as root, but that's not ideal.

BurntSushi · 2011-11-05 04:14:53

How did you install pytyle2?

(You might also try pytyle1 or pytyle3 to see if they work.)

ColInvictus · 2011-11-05 12:05:23

I got it from the mercurial repo, following the instructions here. I haven't tried pytyle1 or 3 yet.

I have to confess I'm not using Arch, I'm using CrunchBang but I hoped it would simply be a case of installing some package or changing some permissions and we could gloss over my choice of distro. We can take any further discussion to the #! forum if you like.

Edit: PyTyle3 gives this error:

Traceback (most recent call last):
  File "/usr/local/bin/pytyle3", line 5, in <module>
    from xpybutil import conn, root
ImportError: cannot import name conn

Last edited by ColInvictus (2011-11-05 14:22:09)

ngoonee · 2011-11-07 04:42:57

ColInvictus wrote:

I have to confess I'm not using Arch, I'm using CrunchBang but I hoped it would simply be a case of installing some package or changing some permissions and we could gloss over my choice of distro. We can take any further discussion to the #! forum if you like.

<modhat on>Please do take the discussion off the Arch forums. Not trying to be unfriendly, but the difference between other distros and Arch can often create messy 'solutions' that won't help either Arch users or users from another distro. Thank you for mentioning this early on though, many aren't as forthright.<modhat off>

arfoll · 2012-02-08 11:55:06

I've just found out about pytyle and I really like it. I'm using pytyle 0.7.5-1 from AUR with openbox.

I'm however having a little trouble with my virtual desktops using pretty much default openbox config, and default pytyle config. It seems it will only let me use Workspaces 2&3 instead of all 4. Weirdest of all my shortcuts W-1 & W-3 don't work but W-2 & W-4 work absolutely fine (they're used to switch from workspace 1-4). Weirdly W-4 gets me to desktop3 instead of 4. Advice?

BurntSushi · 2012-02-11 05:29:38

arfoll - I'm having a lot of difficulty understanding your problem. Could you try to rephrase and be more specific? Do these "shortcuts" refer to those set by pytyle or Openbox? What does your configuration look like? What is the output of pytyle if you run it in a terminal and try a few commands that aren't working but should?

655321 · 2012-02-15 05:45:43

thanks for this, trying it now so far so good, but I have to ask, whats the difference between the 3 packages on AUR? the python version? stable and unstable builds? features? tried to find the info but couldn't

thanks for the app!

BurntSushi · 2012-02-15 16:40:32

655321 wrote:

thanks for this, trying it now so far so good, but I have to ask, whats the difference between the 3 packages on AUR? the python version? stable and unstable builds? features? tried to find the info but couldn't
thanks for the app!

Ah, great question! You have every reason to be confused because I've never made the differences clear.

pytyle1
This is the first version and has been around the longest. Due to that, it is probably the most stable. It uses the Python X Library, which is nearly unmaintained. I don't work on pytyle1 any more, but if someone submitted a patch, I'd apply it.

pytyle2
This version uses xpyb, which is supposed to provide faster access to the X protocol in certain situations. However, since xpyb is a bit more lower level than the Python X Library, pytyle2's codebase is bloated with code to make the xpyb interface usable. The codebase is also poorly designed and ends up consuming a lot of memory if left to its own devices. Finally, it's much slower than pytyle1 or pytyle3. The one thing pytyle2 has over the others is features. There are lots of them. It also attempts to implement manual tiling (Musca style), but fails IMO. I'd sooner fix pytyle1 than pytyle2.

pytyle3
This still uses xpyb, but instead of interfacing with xpyb directly, it uses xpybutil, which is a library I built to hide the lower level implementation details. Moreover, pytyle3 is not as customizable as the other two, but is much faster and has a lower memory footprint. Its codebase is also smaller than pytyle2's by an order of magnitude. Finally, I developed pytyle3 to work specifically with Openbox Multihead. It will still work with the original Openbox, but only on setups with a single monitor.

In short, it's all very confusing. I also didn't handle it very well.

Here's a good decision process for figuring out which to use:

If you have a single monitor and you don't need all of the features of pytyle1, go with pytyle3. (pytyle3 will let you configure the keyboard shortcuts, the windows to ignore, and how much window sizes change whenever you "increment/decrement" their size... but nothing else.) Otherwise, go with pytyle1.

If need or really want more customization, go with pytyle2. You may have to stop and restart it if memory usage gets too big. (Extra features in pytyle2 include: removing window decorations and replacing them with a simple border. Changing the color of those borders. Drag and drop windows from and to different layouts across monitors. Better detection of panels. A more robust configuration system for changing settings on any or all of three levels: monitor, workspace and layout.)

If you have multiple monitors, I implore you to check out Openbox Multihead and go with pytyle3 :-)

655321 · 2012-02-16 18:39:22

BurntSushi wrote:

If you have a single monitor and you don't need all of the features of pytyle1, go with pytyle3. (pytyle3 will let you configure the keyboard shortcuts, the windows to ignore, and how much window sizes change whenever you "increment/decrement" their size... but nothing else.) Otherwise, go with pytyle1.

Pytyle3 it is then (I have only 1 monitor), gonna try it and report back thanks for the detailed information everything is clear now.

Just installed pytyle3, here what I have found so far:
- I think the package should conflict with the other pytyle packages, I installed pytyle3 and didnt prompt me to uninstall pytyle.

- On first run I am getting this:
pytyle3
Openbox window manager is running...
Could not bind Mod1-a
Could not bind Mod1-h
Could not bind Mod1-j
Could not bind Mod1-k
Could not bind Mod1-l
Could not bind Mod1-m
Could not bind Mod1-q
Could not bind Mod1-u
Could not bind Mod1-Shift-k
Could not bind Mod1-Shift-j
Could not bind Mod1-z
Could not bind Mod1-comma
Could not bind Mod1-Return
Could not bind Mod1-period

I am guessing this means that those keybindings failed to bind because they are already in use, right? or is it because of other reasons?

EDIT: Found the culprit, I copied the configuration files from /etc/xdg/pytyle3 but forgot to change the permissions to my user

now I dont get any keybind errors.

Last edited by 655321 (2012-02-16 19:14:38)

adamlau · 2012-02-19 10:44:31

pytyle3 works great with JWM...Except for panel detection. Don't see a work area option in config.py...Is margin specification going to be added to pytyle3?

BurntSushi · 2012-02-20 02:07:19

adamlau wrote:

pytyle3 works great with JWM...Except for panel detection. Don't see a work area option in config.py...Is margin specification going to be added to pytyle3?

You actually shouldn't need to specify a margin---pytyle3 should automatically detect panels and docks if they are behaving.

What panel are you using?

Could you do the following? Open a terminal and run the 'xprop' command. Your mouse should become a crosshair. Click on the panel that pytyle3 is ignoring and paste the output here. (Make sure you put it in code tags.)

Last edited by BurntSushi (2012-02-20 02:07:33)

adamlau · 2012-02-22 07:34:00

Its the default panel provided by JWM:

$ xprop
_WIN_SUPPORTING_WM_CHECK(WINDOW): window id # 0xe0001a
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0xe0001a
_NET_WM_NAME(UTF8_STRING) = "JWM"

nevermind · 2012-02-26 11:54:19

I'm having problem with pytyle3 on openbox, it crashes when I run netbeans (java app):

Traceback (most recent call last):
  File "/usr/bin/pytyle3", line 19, in <module>
    client.update_clients()
  File "/usr/lib/python2.7/site-packages/pt3/client.py", line 189, in update_clients
    track_client(c)
  File "/usr/lib/python2.7/site-packages/pt3/client.py", line 197, in track_client
    if not should_ignore(client):
  File "/usr/lib/python2.7/site-packages/pt3/client.py", line 225, in should_ignore
    inst, cls = wm_class
ValueError: need more than 1 value to unpack

Last edited by nevermind (2012-02-26 11:56:25)

BurntSushi · 2012-02-26 21:03:20

@nevermind - Nice catch. Silly Java apps...

I've added a fix that should prevent pytyle from crashing on you, however, it will ignore the "window class" completely. (Which means that you won't be able to tell pytyle to ignore that window.)

I might be able to fix this better if you could do the following: run `xprop` in a terminal. Your mouse will turn into crosshairs. Now click on your NetBeans window. Copy and paste the output of xprop here. (In code tags.)

Last edited by BurntSushi (2012-02-26 21:33:57)

BurntSushi · 2012-02-26 21:04:41

@adamlau - Yeah, it looks like JWM isn't setting struts on your panel so pytyle doesn't detect it. (Those egotistical window managers, thinking that they're the only ones who use struts!)

Anyway, I suppose that's a valid reason for wanting margins. I'll see what I can do.

*EDIT*

I've updated pytyle3 in the AUR to include support for margins. After you update, check out /etc/xdg/pytyle3/config.py for how to use margins. (Make sure to set 'use_margins' to True!)

Last edited by BurntSushi (2012-02-26 21:33:34)

nevermind · 2012-02-27 09:59:34

BurntSushi wrote:

@nevermind - Nice catch. Silly Java apps...
I've added a fix that should prevent pytyle from crashing on you, however, it will ignore the "window class" completely. (Which means that you won't be able to tell pytyle to ignore that window.)
I might be able to fix this better if you could do the following: run `xprop` in a terminal. Your mouse will turn into crosshairs. Now click on your NetBeans window. Copy and paste the output of xprop here. (In code tags.)

yeah, I hate java apps, problems everywhere

Here is the output from xprop:

_NET_WM_ICON_GEOMETRY(CARDINAL) = 490, 1052, 140, 28
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 21, 5
_OB_APP_TYPE(UTF8_STRING) = "normal"
_OB_APP_TITLE(UTF8_STRING) = "NetBeans IDE 7.1"
_OB_APP_CLASS(UTF8_STRING) = "java-lang-Thread"
_OB_APP_NAME(UTF8_STRING) = "sun-awt-X11-XFramePeer"
_OB_APP_ROLE(UTF8_STRING) = 
_NET_WM_VISIBLE_ICON_NAME(UTF8_STRING) = "aurron-web - NetBeans IDE 7.1"
_NET_WM_VISIBLE_NAME(UTF8_STRING) = "aurron-web - NetBeans IDE 7.1"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x1, 0x1, 0x0, 0x0
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x42, 0x0, 0x60, 0x1, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_STATE(ATOM) = 
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		Initial state is Normal State.
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 21, 5
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _OB_WM_ACTION_UNDECORATE
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 2, 40
		program specified location: 2, 40
		program specified size: 952 by 1012
		window gravity: NorthWest
_NET_WM_ICON(CARDINAL) = 	Icon (16 x 16):
	       ▒▓▒░     
	    ░▓▓▒░░▒▓▒░  
	  ░▓▒░      ▒▓▓░
	 ░▒░          ░▒
	 ▓░░░          ▓
	 ▓▒░░░░       ░▓
	 ▒▒░░░░░      ░▓
	 ▒▒░░░░░      ░▓
	 ▒▒░░░░░     ░░▓
	 ▒▒░░░░░     ░░▓
	 ▒▒░░░░░    ░░░▓
	 ▒▒░░░░░   ░░░░▓
	  ▓▒░░░░   ░░░▓░
	   ▒▓▒░░   ░▓▓░ 
	     ▒▓▒░░▓▓░   
	       ▒▓▒░     

	Icon (32 x 32):
	             ░▒▒▒░              
	          ░▒▓▓▓▓▓▓▓▒░           
	        ▒▓▓▓▓▓▒░▒▒▓▓▓▓▒         
	     ░▒▓▓▓▓▒░     ░▒▓▓▓▓▒░      
	   ▒▓▓▓▓▒░           ░▒▓▓▓▓▒    
	 ▒▓▓▓▓▒░               ░▒▓▓▓▓▒  
	 ▓▓▓░                     ░▓▓▓  
	░▓▓░░░                   ░░ ▓▓▒ 
	▒▓▒░ ░░░               ░░   ░▓▒ 
	▒▓▒░░░  ░░░         ░░      ░▓▓ 
	▒▓▒░░░░░  ░░░     ░░        ▒▓▓ 
	▒▓▒░░░░░░░░  ░░░░          ░▒▓▒ 
	▒▓▒░░░░░░░░░░             ░░▒▓▒ 
	▒▓▓░░░░░░░░░░░            ░░▒▓▒ 
	▒▓▒░░░░░░░░░░░░          ░░░▒▓▒ 
	▒▓▒░░░░░░░░░░░░          ░░░▒▓▒ 
	▒▓▓░░░░░░░░░░░░         ░░░░▒▓▒ 
	░▓▓░░░░░░░░░░░░         ░░░░▒▓▒ 
	░▓▓▒░░░░░░░░░░░        ░░░░░▒▓░ 
	░▓▓▒░░░░░░░░░░░       ░░░░░░▒▓░ 
	░▓▓▒░░░░░░░░░░░       ░░░░░░▓▓░ 
	░▓▓▒░░░░░░░░░░░      ░░░░░░░▒▓░ 
	░▓▓▒░░░░░░░░░░░      ░░░░░░░▓▓░ 
	 ▓▓▒░░░░░░░░░░░     ░░░░░░░░▓▓  
	 ▒▓▓▒░░░░░░░░░░     ░░░░░░▒▓▓▒  
	  ▒▓▓▓▒░░░░░░░░    ░░░░░▒▓▓▓▒   
	   ░▓▓▓▓▒░░░░░░   ░░░░▒▓▓▓▓▒    
	     ░▓▓▓▓▒░░░░   ░░▒▓▓▓▓▒      
	       ▒▓▓▓▓▒░░  ░▒▓▓▓▓▒        
	         ▒▓▓▓▓▒░▒▓▓▓▓▒          
	           ▒▓▓▓▓▓▓▓▒            
	             ░▒▒▒░              

	Icon (48 x 48):
	                     ░▒▒▒░░                     
	                  ░▓▓▓▓▓▓▓▓▓░                   
	               ░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░                
	             ▒▓▓▓▓▓▓▓▒░░░▒▓▓▓▓▓▓▓▒              
	          ░▓▓▓▓▓▓▓▒▒       ░▒▓▓▓▓▓▓▓░           
	       ░▒▓▓▓▓▓▓▓▒░           ░▒▓▓▓▓▓▓▓▒░        
	     ░▓▓▓▓▓▓▓▒░                 ░▒▓▓▓▓▓▓▓░      
	   ░▓▓▓▓▓▓▓▒░                     ░▒▓▓▓▓▓▓▓░    
	  ▒▓▓▓▓▓▒░                           ░▒▓▓▓▓▓▒   
	 ░▓▓▓▓▒                                 ▒▓▓▓▓▒  
	 ▓▓▓▓░░                                 ░░▒▓▓▓  
	 ▓▓▓▒░░░░░                           ░░░░ ░▓▓▓░ 
	░▓▓▓░░  ░░░░                       ░░░     ▒▓▓░ 
	░▓▓▓░░░░   ░░░░                  ░░░       ▒▓▓▒ 
	░▓▓▓▒░░░░░   ░░░░             ░░░         ░▒▓▓▒ 
	░▓▓▓▒░░░░░░░░   ░░░         ░░░           ░▒▓▓▒ 
	░▓▓▓▒░░░░░░░░░░   ░░░░   ░░░             ░░▒▓▓▒ 
	░▓▓▓▒░░░░░░░░░░░░    ░░░░░               ░░▒▓▓░ 
	░▓▓▓▒░░░░░░░░░░░░░░░                    ░░░▒▓▓░ 
	░▓▓▓▒░░░░░░░░░░░░░░░░                  ░░░░▓▓▓░ 
	░▓▓▓▒░░░░░░░░░░░░░░░░░                 ░░░░▓▓▓░ 
	 ▓▓▓▒░░░░░░░░░░░░░░░░░░               ░░░░░▓▓▓░ 
	 ▓▓▓▒░░░░░░░░░░░░░░░░░░               ░░░░░▓▓▓░ 
	 ▓▓▓▒░░░░░░░░░░░░░░░░░░              ░░░░░░▓▓▓░ 
	 ▓▓▓▒░░░░░░░░░░░░░░░░░░              ░░░░░░▓▓▓░ 
	 ▓▓▓▒░░░░░░░░░░░░░░░░░              ░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░              ░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░             ░░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░             ░░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░            ░░░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░            ░░░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░           ░░░░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░          ░░░░░░░░░░░▓▓▓  
	 ▓▓▓▒▒░░░░░░░░░░░░░░░░          ░░░░░░░░░░▒▓▓▓  
	 ▒▓▓▒░▒░░░░░░░░░░░░░░░         ░░░░░░░░░░░▒▓▓▒  
	 ░▓▓▓░░░░░░░░░░░░░░░░░         ░░░░░░░░░░░▓▓▓░  
	  ▓▓▓▓▒░░░░░░░░░░░░░░░        ░░░░░░░░░░░▓▓▓▓   
	  ░▓▓▓▓▓▒░░░░░░░░░░░░░        ░░░░░░░░░▒▓▓▓▓░   
	   ░▓▓▓▓▓▓▒░░░░░░░░░░░       ░░░░░░░░▒▓▓▓▓▓░    
	     ▒▓▓▓▓▓▓▒░░░░░░░░░      ░░░░░░░▒▓▓▓▓▓▒      
	       ▒▓▓▓▓▓▓▒░░░░░░░     ░░░░░░▒▓▓▓▓▓▓        
	         ▒▓▓▓▓▓▓▒░░░░░     ░░░░▒▓▓▓▓▓▓░         
	           ▒▓▓▓▓▓▓▒░░░    ░░░▒▓▓▓▓▓▒            
	             ▒▓▓▓▓▓▓▒░░   ░▒▓▓▓▓▓▒              
	               ▒▓▓▓▓▓▓▒▒▒▒▓▓▓▓▓▒                
	                 ▒▓▓▓▓▓▓▓▓▓▓▓▓                  
	                   ▒▓▓▓▓▓▓▓▒                    
	                     ░▒▒▒░                      


WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "java-lang-Thread"
WM_CLIENT_LEADER(WINDOW): window id # 0x1600005
_NET_WM_ICON_NAME(UTF8_STRING) = "aurron-web - NetBeans IDE 7.1"
WM_ICON_NAME(STRING) = "aurron-web - NetBeans IDE 7.1"
_NET_WM_NAME(UTF8_STRING) = "aurron-web - NetBeans IDE 7.1"
WM_NAME(STRING) = "aurron-web - NetBeans IDE 7.1"

ERiS · 2012-03-23 17:56:24

Firefox doesn't tile if it's not the first window to pop-up.
For example, if I start up my computer, and launch firefox, it will take whatever position it was in last. Then if I start terminator, it will be tiled, but Firefox is still floating in the same place as before.

This might have been mentioned already but I didn't see it when I searched. If someone knows how to fix it, please let me know.

~ ~ ~ ~ ~ ~ ~ ~
By the way, how to make it so:
* tiling starts /automatically/ in desktop 1, vertical mode
* tiling starts /automatically/ in desktop 2, vertical mode
* tiling does NOT start in desktop 3

It seems I can only set to start automatically on all. I hate having to Alt-a.

Last edited by ERiS (2012-03-23 19:41:41)

Arch Linux

#201 2011-08-04 15:09:26

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

#202 2011-08-04 23:03:47

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

#203 2011-08-05 00:15:26

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

#204 2011-08-09 09:10:31

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

#205 2011-08-09 15:44:51

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

#206 2011-08-09 22:26:10

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

#207 2011-08-09 23:01:51

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

#208 2011-08-11 07:28:15

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

#209 2011-11-05 03:25:53

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

#210 2011-11-05 04:14:53

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

#211 2011-11-05 12:05:23

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

#212 2011-11-07 04:42:57

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

#213 2012-02-08 11:55:06

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

#214 2012-02-11 05:29:38

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

#215 2012-02-15 05:45:43

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

#216 2012-02-15 16:40:32

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

#217 2012-02-16 18:39:22

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

#218 2012-02-19 10:44:31

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

#219 2012-02-20 02:07:19

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

#220 2012-02-22 07:34:00

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

#221 2012-02-26 11:54:19

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

#222 2012-02-26 21:03:20

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

#223 2012-02-26 21:04:41

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

#224 2012-02-27 09:59:34

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

#225 2012-03-23 17:56:24

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

Board footer