Openbox Multihead (featuring per-monitor desktops) + pytyle3

BurntSushi · 2011-08-11 22:13:04

This is a branch of the current Openbox master called "multihead"; and single head users need not apply

I've explained most of the details in the README.MULTIHEAD:

=======================================================
This is the multihead branch of Openbox, which features better support for
multiple monitors when using the Xinerama extension. (Which will implicitly
support users using TwinView and RandR.)

What's different?
=================

The biggest difference by far is the change in the desktop model.

In traditional Openbox (and indeed, in most window managers), there can only be
one desktop viewable at any time. Namely, even when there are multiple monitors
active, a single desktop spans all available monitors.

In Openbox Multihead, each monitor gets it own desktop. Namely, monitors can
switch its currently active desktop independent of the other monitors. This
makes workflow much more dynamic in multi-monitor setups, since it allows finer
control over what you can see at any point in time.

There is a price to pay, however; to make "independent desktops" work, Openbox
needs to break the Extended Window Manager Hints spec. In particular, it
violates the assumption that one and only one desktop is viewable at any point
in time. This results in a significant loss of functionality in existing
pagers. (They won't break, but what it shows you will be confusing.)

To remedy this, I've provided a small Python script ('ob-visible-desks') that
acts as a simple text-based (and non-interactive) pager. My plan is to build
something more elaborate, but this will have to do for now.

You can pipe the output of 'ob-visible-desks' to a status bar like dzen or
xmobar. For example:

ob-visible-desks | dzen2 -dock

While it isn't ideal, you can modify the colors at the top of the script itself.
It groups each desktop into one of four categories: current, visible, hidden
with windows and hidden without windows.

This script should be considered temporary and will probably be removed in the
future in favor of something released separately.

A new desktop list menu
=======================

Another downside of independent desktops is that it makes the "next/prev
desktop" functions a bit quirky. To help remedy this, there is a new menu
called 'desktop-list-menu' that will give a simple list of desktops; which
provides a simple mechanism of switching to any desktop.

New configuration options
=========================

Greedy desktop switching
------------------------
In the "<desktops>" section, a new boolean option "<greedy>" has been added.
When it is enabled, it makes desktop switching "greedy." In particular, if you
are switching to a desktop that is already visible, instead of going to the
monitor that desktop is on, the desktop will be brought to the monitor you are
currently on (and will put the current desktop on the other monitor).

A new action 'FocusRoot'
------------------------
Openbox already provides one the ability of moving clients to another monitor
via the 'MoveResizeTo' action, but it does not provide the ability to move
*focus* from one monitor to the next. This is precisely what 'FocusRoot'
provides.

It has two child options, "<monitor>" and "<pointer>". The former is required
and the latter is optional. The former specifies a monitor index starting from
1, or a relative monitor position ("next" or "prev").

The "<pointer>" option allows you to move the pointer with the focus. It takes
two child options "<x>" and "<y>". They should be specified relative to the
monitor being focused. Negative values are allowed.

Transparent inactive windows (easter egg)
-----------------------------------------
In the "<focus>" section, a new option "<inactiveOpacity>" has been added. Its
value should be interpreted as a percentage where 100 is full opaqueness (and
disables the feature) and 0 is full transparency (invisible).

This option simply sets the opacity level of all inactive windows. You'll need
a compositing manager for it to actually work, though.
=======================================================

Most of these ideas are almost directly lifted from Xmonad, in particular, the desktop model.

My plans for the future are to keep this branch up to date with Dana's master branch of Openbox, and continue to develop features related to improving the multi-head experience. I will also be working on a specialized version of pytyle that will work with openbox-multihead (it doesn't work currently).

If you install over a current version of Openbox, please make sure to update your configuration file (see /etc/xdg/openbox/rc.xml) with the new options listed above in the README. Particularly the greedy option and the FocusRoot actions.

I am currently running this on my triple monitor setup. I've also briefly tested it on my laptop (with a single screen) and it appears to work just like the normal Openbox.

openbox-multihead-git in the AUR

git repo

Last edited by BurntSushi (2011-08-17 22:31:49)

karol · 2011-08-11 22:21:04

Please wrap this looong piece of text in [ code ] tags so we can conveniently scroll through it.

ArchArael · 2011-08-12 09:40:57

Interesting. Have you contacted Dana Jansens? If you have what has been her reaction to this project?

EDIT: Check my next comment.

Last edited by ArchArael (2011-08-12 14:51:49)

BurntSushi · 2011-08-12 13:46:38

ArchArael wrote:

Interesting. Have you contacted Dana Jansens? If you have what has been his reaction to this project?

I've sent an email to the mailing list, but I haven't received a response from her yet.

ArchArael · 2011-08-12 14:48:51

BurntSushi wrote:

... from her yet.

http://cg.scs.carleton.ca/~dana/

Didn't know that Dana is a girl. *_______*

BurntSushi · 2011-08-16 14:28:01

I've had some people ask me why this is useful, and someone gave me this great explanation on the xmonad web site.

BurntSushi · 2011-08-17 22:31:25

I've finished a first cut at pytyle 3 (AUR), which is compatible with Openbox Multihead and single head regular Openbox users. It will not work with multihead users using regular Openbox.

README:

An updated (and much faster) version of pytyle that uses xpybutil and is
compatible with Openbox Multihead.
Due to using xpybutil much of the lower level XCB/xpyb stuff has been factored
out of pytyle3. Also, because it relies on Openbox Multihead when there is more
than one monitor active, a lot less state needs to be saved.
As a result, pytyle3 is ~1000 lines while pytyle2 is ~7000 lines. Additionally,
because of a simpler design, pytyle3's memory footprint is much smaller and is
actually quite snappier in moving windows on the screen.

spazzwig · 2011-09-08 20:25:00

Running in ob multihead now, pretty cool and only a couple minor quirks so far (mostly with the way some autostart programs window positions worked out).

My main interest is pytyle 3, unfortunately it won't build, keeps complaining about missing xpybutil (xpybutil-git is installed, and I updated it's pkgbuild to make sure provides/conflicts for xpybutil was there just in case). Seems to be something in the code pulled from git that isn't detecting it. I haven't had a chance to look at the code tho, just basing that off no evident issues in the pkgbuild and that the error out is in the build process after git pull / switch to master. EDIT: nvm, sourced profile to make sure it was added to path env vars and it built fine.

Looking forward to trying this out, good timing as I was just considering switching (from openbox with pytyle2) to xmonad or awesome.

Edit2:
pytyle3 crashes for me, with the following:

Openbox window manager is running...
Traceback (most recent call last):
  File "/usr/bin/pytyle3", line 20, in <module>
    client.update_clients()
  File "/usr/lib/python2.7/site-packages/pt3/client.py", line 193, in update_clients
    track_client(c)
  File "/usr/lib/python2.7/site-packages/pt3/client.py", line 201, in track_client
    if not should_ignore(client):
  File "/usr/lib/python2.7/site-packages/pt3/client.py", line 229, in should_ignore
    inst, cls = wm_class
ValueError: need more than 1 value to unpack

Last edited by spazzwig (2011-09-08 20:39:51)

BurntSushi · 2011-09-09 22:40:37

Thanks for testing it out!

Could you copy this code into some file named 'get-win-classes.py'?

from xpybutil import conn, root
import xpybutil.ewmh as ewmh
import xpybutil.icccm as icccm

clients = ewmh.get_client_list(conn, root).reply()
for c in clients:
    print ewmh.get_wm_name(conn, c).reply()
    print icccm.get_wm_name(conn, c).reply()
    print icccm.get_wm_class(conn, c).reply()
    print '-' * 45

Then run it with `python2 get-win-classes.py` and paste the output here.

Last edited by BurntSushi (2011-09-09 22:40:48)

vileperson · 2011-09-10 14:19:58

this may be exactly what I am looking for as a 3 monitor solution. I currently run openbox but have yet to configure multi head support. Once I get my configs in order and actually have all 3 displays working, I'll have to check this out. Any screenshots of setups using this?

BurntSushi · 2011-09-10 14:59:32

vileperson wrote:

this may be exactly what I am looking for as a 3 monitor solution. I currently run openbox but have yet to configure multi head support. Once I get my configs in order and actually have all 3 displays working, I'll have to check this out. Any screenshots of setups using this?

The appearance of the setup via screenshot isn't any different than what you would get with regular Openbox.

With Openbox Multihead my pager-multihead is going to be pretty useful, since Openbox MH necessarily breaks the EWMH assumption of "one desktop is viewable at any time." Thus, existing pagers are a bit screwy and confusing.

Here are some screenshots with Openbox MH and pager-multihead.

There is also vim-like window marking.

Make sure you read the latest README.MULTIHEAD.

vileperson · 2011-09-10 15:04:00

Nice. Don't suppose you are running 2 nvidia cards and have some configs you could throw my way, do ya?

BurntSushi · 2011-09-10 15:43:25

vileperson wrote:

Nice. Don't suppose you are running 2 nvidia cards and have some configs you could throw my way, do ya?

Nope. See success with triple monitors using eyefinity and xf86-video-ati.

karamorf · 2011-09-27 18:40:27

looks like you are now having some problems with regexp in c?

== Starting build()...
for dir in cmd Instant Transpec; \
do (cd $dir; make all); \
done
make[1]: Entering directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/cmd'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/cmd'
make[1]: Entering directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Instant'
cd tptregexp; make all
gcc -o instant -g main.o util.o info.o translate.o traninit.o tranvar.o tables.o browse.o masterVersion.o -Ltptregexp -ltptregexp
make[2]: Entering directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Instant/tptregexp'
gcc -O  -I.    -c -o regexp.o regexp.c
/usr/bin/ld: cannot find -ltptregexp
collect2: ld returned 1 exit status
make[1]: *** [instant] Error 1
make[1]: *** Waiting for unfinished jobs....
regexp.c: In function ‘tpt_regcomp’:
regexp.c:199:15: error: conflicting types for ‘malloc’
regexp.c: In function ‘tpt_regexec’:
regexp.c:708:22: error: macro strchr requires 2 arguments, but only 1 given
regexp.c:708:15: error: ‘strchr’ redeclared as different kind of symbol
regexp.c: In function ‘regmatch’:
regexp.c:807:22: error: macro strchr requires 2 arguments, but only 1 given
make[2]: *** [regexp.o] Error 1
make[2]: Leaving directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Instant/tptregexp'
make[1]: *** [dotptregexp] Error 2
make[1]: Leaving directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Instant'
make[1]: Entering directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Transpec'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Transpec'
for dir in cmd Instant Transpec; \
do (cd $dir; make ROOT=/tmp/clyde-gour/docbook-to-man/docbook-to-man/pkg/usr/ install); \
done
make[1]: Entering directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/cmd'
cat docbook-to-man.sh docbook-to-man 
chmod a+x docbook-to-man
cp docbook-to-man /tmp/clyde-gour/docbook-to-man/docbook-to-man/pkg/usr//bin
make[1]: Leaving directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/cmd'
make[1]: Entering directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Instant'
cd tptregexp; make all
gcc -o instant -g main.o util.o info.o translate.o traninit.o tranvar.o tables.o browse.o masterVersion.o -Ltptregexp -ltptregexp
/usr/bin/ld: cannot find -ltptregexp
collect2: ld returned 1 exit status
make[2]: Entering directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Instant/tptregexp'
gcc -O  -I.    -c -o regexp.o regexp.c
make[1]: *** [instant] Error 1
make[1]: *** Waiting for unfinished jobs....
regexp.c: In function ‘tpt_regcomp’:
regexp.c:199:15: error: conflicting types for ‘malloc’
regexp.c: In function ‘tpt_regexec’:
regexp.c:708:22: error: macro strchr requires 2 arguments, but only 1 given
regexp.c:708:15: error: ‘strchr’ redeclared as different kind of symbol
regexp.c: In function ‘regmatch’:
regexp.c:807:22: error: macro strchr requires 2 arguments, but only 1 given
make[2]: *** [regexp.o] Error 1
make[2]: Leaving directory `/tmp/clyde-gour/docbook-to-man/docbook-to-man/src/docbook-to-man/Instant/tptregexp'
make[1]: *** [dotptregexp] Error 2

Let me know what I can do to help ... been a while since I've worked with C though, LAMP is more my realm of knowledge ...

rod · 2011-11-25 15:26:08

Very very nice. it is excellent, THANKS. specially in laptos that doesn't support real multihead (i.e. only virtual monitor multihead).

I had not reviewed the code too much, but I was only wondering if the the behaviour could be modify by having two pointers (one for each of the screens) to the desktop list completelly independent one from each other. In this way, each of the two screens could circulate through the desktop list independently, even having a clone monitor when both pointers address the same desktop. In this way, it would not be necessary to have the greedy option and the movement through the desktops would be more logical. This would possibly make easier for other pager and standard openbox tools to work with (at least in one of the two pointers - a foculs swap could be done later on).

In any of the cases, excellent job gentleman.

Geek_Daddy · 2012-01-17 12:55:27

I have problem with pytyle3. It dosen't capture keybind. I use xfce (panels and session), openbox (as wm) and on top of this pytyle3. Pytyle has default config copied from /etx/xdg/pytyle3/ to ~/.config/pytyle3/. I've removed every keybinding duplicated from pytytle ine openbox rc.xml. I think xfce thosen't capture them beacouse when I press, lets say, win+a in urxvt I get posted 'a'. Any solutions?

PS. sorry for my bad english

Last edited by Geek_Daddy (2012-01-17 13:12:33)

BurntSushi · 2012-01-18 17:01:47

Can you run pytyle3 on the command line with 'pytyle3 --debug'? Try a few commands and post the output here.

GSF1200S · 2012-05-12 02:33:50

Im really thinking about switching from a Separate X setup to this; im getting tired of bugs in apps relating to systems running Separate X configurations. Are you planning on keeping this up?

Also, any future plans for an interactive workspace switcher (or maybe adapting an already existing one [stalone tray, etc])? I know you mentioned eventually working on this, but I also know that you have mentioned being very busy as of late... Openbox with Pytyle 1 has been nearly perfect for me (except libreoffice failing to open on screen 2, system tray apps not presenting on current workspace due to separate x bugs, etc etc etc!), so having workspaces on each screen with ability to move apps between screens seems great- does the workspace switcher (alt+tab) and client list menu also honor the fact that there are different workspaces for each screen?

Thanks again for Pytyle1- I use it all the time and hope it continues to work for a long time

Last edited by GSF1200S (2012-05-12 02:34:42)

BurntSushi · 2012-05-12 03:47:07

GSF1200S wrote:

Im really thinking about switching from a Separate X setup to this; im getting tired of bugs in apps relating to systems running Separate X configurations. Are you planning on keeping this up?

As of right now, Openbox Multihead is in a good state. As long as I'm still using it, I'll continue to merge it with changes upstream. (Such changes are not frequent. Openbox is pretty stable.)

However, I am working on a new window manager written in Go that is (about) a month away from an initial public release. (It is not currently usable.) It will embody the changes I've made to Openbox (i.e., the better multihead support) but will also contain tiling built in. (So pytyle will no longer be necessary.) It's taking a bit long to develop because I've had to port the entire X client API over to Go. (From XCB on up.)

Wingo has two concurrent, equally import goals:

1) Provide a solid floating placement strategy and a solid tiling placement strategy. Few window managers do this: they typically excel in one and lack in the other.

2) Provide excellent multi-head support with a model like Xmonad (and indeed, like Openbox Multihead).

Basically, Wingo is heavily inspired by both Openbox and Xmonad. It has Openbox-style floating, decorations, alt-tab, EWMH support, etc. It also has Xmonad style tiling, dynamic workspaces, prompts, and multi-head support.

If and when Wingo becomes my active window manager, it's quite likely that support from me for Openbox Multihead and pytyle will drop off considerably. (I have zero problems with someone else taking over. I just won't have the bandwidth to do it myself.)

GSF1200S wrote:

Also, any future plans for an interactive workspace switcher (or maybe adapting an already existing one [stalone tray, etc])? I know you mentioned eventually working on this, but I also know that you have mentioned being very busy as of late... Openbox with Pytyle 1 has been nearly perfect for me

Yes! A pager is nearly necessary to use Openbox Mutlihead effectively, because "Next" and "Previous" workspaces no longer make much sense. (Although, you can use the workspace menu built into Openbox to navigate too.)

Here is the pager-multihead homepage. It is also in the AUR.

pager-multihead really needs some documentation. But basically, after install, copy the two config files from /etc/xdg/pager-multihead/*.py to $HOME/.config/pager-multihead/. The two config files are 'config.py' and 'keymousebind.py'. 'config.py' contains various presentation options, including colors, size, position, fonts, etc.

keymousebind.py configures the key bindings. Due to the pager's dynamic nature, this is a bit complicated. But you can start with Super+Return to bring up the workspace prompt. (It has tab completion, and typing in a workspace name will switch to it. If the name doesn't exist, a new workspace will be created.) Super+BackSpace deletes the current workspace (if it has no windows on it). And Super+Shift+Return is the same as Super+Return, except it will move the currently active window to the workspace specified. Also, Super+space will bring up a list of windows on the current workspace, and Super+Alt+space will show a listing of all windows.

There are also bindings for Control+Alt+A, Control+Alt+B, ..., Control+Alt+Z that cycle through workspaces starting with each corresponding letter.

All of these bindings can be reconfigured, but I'm afraid you might need a barely passing familiarity with Python.

And finally, just run it with 'pager-multihead'.

GSF1200S wrote:

(except libreoffice failing to open on screen 2, system tray apps not presenting on current workspace due to separate x bugs, etc etc etc!)

Yeah, many of us developing X applications aren't very cognizant of users on separate screens. In theory, we shouldn't have to do anything special. But you know, in theory, theory and practice are the same. In practice, they are different.

And libreoffice is not a friendly X application. *vomit*

GSF1200S wrote:

, so having workspaces on each screen with ability to move apps between screens seems great- does the workspace switcher (alt+tab) and client list menu also honor the fact that there are different workspaces for each screen?

I believe alt+tab works as one would expect. You can still fiddle with all the options Openbox gives you by default in that area. I've also added a new list menu called 'desktop-list-menu'. Finally, I'm not sure how the client list menu should honor multiple heads---when you select a new client, it should simply focus it. If it's on a different workspace, then you'll switch to that workspace.

The README.MULTIHEAD contains a more detailed breakdown.

GSF1200S wrote:

Thanks again for Pytyle1- I use it all the time and hope it continues to work for a long time

pytyle1 is still going strong, but I don't actively develop it anymore. There is also a pytyle2 and a pytyle3.

If you switch to Openbox Multihead and you have multiple heads, then you must use pytyle3 in lieu of pytyle1 or pytyle2. pytyle[12] will fail on Openbox Multihead when more than one head is present.

pytyle3 represents a slight feature regression from pytyle1, but I think the critical stuff is still there. pytyle3 is in the AUR.

GSF1200S · 2012-05-12 04:31:27

BurntSushi wrote:

GSF1200S wrote:
Im really thinking about switching from a Separate X setup to this; im getting tired of bugs in apps relating to systems running Separate X configurations. Are you planning on keeping this up?
As of right now, Openbox Multihead is in a good state. As long as I'm still using it, I'll continue to merge it with changes upstream. (Such changes are not frequent. Openbox is pretty stable.)
However, I am working on a new window manager written in Go that is (about) a month away from an initial public release. (It is not currently usable.) It will embody the changes I've made to Openbox (i.e., the better multihead support) but will also contain tiling built in. (So pytyle will no longer be necessary.) It's taking a bit long to develop because I've had to port the entire X client API over to Go. (From XCB on up.)
Wingo has two concurrent, equally import goals:
1) Provide a solid floating placement strategy and a solid tiling placement strategy. Few window managers do this: they typically excel in one and lack in the other.
2) Provide excellent multi-head support with a model like Xmonad (and indeed, like Openbox Multihead).
Basically, Wingo is heavily inspired by both Openbox and Xmonad. It has Openbox-style floating, decorations, alt-tab, EWMH support, etc. It also has Xmonad style tiling, dynamic workspaces, prompts, and multi-head support.
If and when Wingo becomes my active window manager, it's quite likely that support from me for Openbox Multihead and pytyle will drop off considerably. (I have zero problems with someone else taking over. I just won't have the bandwidth to do it myself.)
GSF1200S wrote:
Also, any future plans for an interactive workspace switcher (or maybe adapting an already existing one [stalone tray, etc])? I know you mentioned eventually working on this, but I also know that you have mentioned being very busy as of late... Openbox with Pytyle 1 has been nearly perfect for me
Yes! A pager is nearly necessary to use Openbox Mutlihead effectively, because "Next" and "Previous" workspaces no longer make much sense. (Although, you can use the workspace menu built into Openbox to navigate too.)
Here is the pager-multihead homepage. It is also in the AUR.
pager-multihead really needs some documentation. But basically, after install, copy the two config files from /etc/xdg/pager-multihead/*.py to $HOME/.config/pager-multihead/. The two config files are 'config.py' and 'keymousebind.py'. 'config.py' contains various presentation options, including colors, size, position, fonts, etc.
keymousebind.py configures the key bindings. Due to the pager's dynamic nature, this is a bit complicated. But you can start with Super+Return to bring up the workspace prompt. (It has tab completion, and typing in a workspace name will switch to it. If the name doesn't exist, a new workspace will be created.) Super+BackSpace deletes the current workspace (if it has no windows on it). And Super+Shift+Return is the same as Super+Return, except it will move the currently active window to the workspace specified. Also, Super+space will bring up a list of windows on the current workspace, and Super+Alt+space will show a listing of all windows.
There are also bindings for Control+Alt+A, Control+Alt+B, ..., Control+Alt+Z that cycle through workspaces starting with each corresponding letter.
All of these bindings can be reconfigured, but I'm afraid you might need a barely passing familiarity with Python.
And finally, just run it with 'pager-multihead'.
GSF1200S wrote:
(except libreoffice failing to open on screen 2, system tray apps not presenting on current workspace due to separate x bugs, etc etc etc!)
Yeah, many of us developing X applications aren't very cognizant of users on separate screens. In theory, we shouldn't have to do anything special. But you know, in theory, theory and practice are the same. In practice, they are different.
And libreoffice is not a friendly X application. *vomit*
GSF1200S wrote:
, so having workspaces on each screen with ability to move apps between screens seems great- does the workspace switcher (alt+tab) and client list menu also honor the fact that there are different workspaces for each screen?
I believe alt+tab works as one would expect. You can still fiddle with all the options Openbox gives you by default in that area. I've also added a new list menu called 'desktop-list-menu'. Finally, I'm not sure how the client list menu should honor multiple heads---when you select a new client, it should simply focus it. If it's on a different workspace, then you'll switch to that workspace.
The README.MULTIHEAD contains a more detailed breakdown.
GSF1200S wrote:
Thanks again for Pytyle1- I use it all the time and hope it continues to work for a long time
pytyle1 is still going strong, but I don't actively develop it anymore. There is also a pytyle2 and a pytyle3.
If you switch to Openbox Multihead and you have multiple heads, then you must use pytyle3 in lieu of pytyle1 or pytyle2. pytyle[12] will fail on Openbox Multihead when more than one head is present.
pytyle3 represents a slight feature regression from pytyle1, but I think the critical stuff is still there. pytyle3 is in the AUR.

If you manage to actually get Wingo to work out, I will undoubtedly be your first user- that sounds absolutely EXACTLY what im looking for. Pytyle does this very admirably, with the caveats that its not quite as fast as a tiling window manager and you lose some screen space with window decorations (not too big of a deal on 24" 1080p screens, but still..). Overall, I have been immensely pleased with Openbox and Pytyle over Awesome or Xfwin, etc..

Can I request one feature? Client-list menu (or like it) for wingo. Your choice of course, but I use that so much I couldnt live without it. Hopefully I can get used to having only one system tray so I could run Wingo on twinview instead of bug-ridden separate X (should work in theory ), but if not hopefully Wingo will work on separate X as well. Where will you be announcing it if you manage to get it developed? Ill be keeping an eye out.

BurntSushi · 2012-05-13 00:47:01

GSF1200S wrote:

If you manage to actually get Wingo to work out, I will undoubtedly be your first user- that sounds absolutely EXACTLY what im looking for. Pytyle does this very admirably, with the caveats that its not quite as fast as a tiling window manager and you lose some screen space with window decorations (not too big of a deal on 24" 1080p screens, but still..). Overall, I have been immensely pleased with Openbox and Pytyle over Awesome or Xfwin, etc..

:-)

GSF1200S wrote:

Can I request one feature? Client-list menu (or like it) for wingo. Your choice of course, but I use that so much I couldnt live without it.

I don't plan on implementing menus like Openbox for the initial release, but it does have prompts. They are pretty similar to menus and should accomplish the same task.

Right now, there is a prompt that shows a list of all windows organized by workspace. (And this can be configure to show only visible windows, or only windows on the same workspace.) You can then select a window to activate using tab completion.

GSF1200S wrote:

Hopefully I can get used to having only one system tray so I could run Wingo on twinview instead of bug-ridden separate X (should work in theory ), but if not hopefully Wingo will work on separate X as well.

Indeed, it should work on separate X screens. I'd be willing to invest some time to fixing bugs in this kind of setup, but I don't think I'd be willing to support it if it required a pervasive change. (It really shouldn't.)

GSF1200S wrote:

Where will you be announcing it if you manage to get it developed? Ill be keeping an eye out.

At the very least, I'll post a thread in this forum. I'll also probably post it to reddit and the XCB mailing list.

whenov · 2012-06-11 15:48:41

BurntSushi wrote:

Basically, Wingo is heavily inspired by both Openbox and Xmonad. It has Openbox-style floating, decorations, alt-tab, EWMH support, etc. It also has Xmonad style tiling, dynamic workspaces, prompts, and multi-head support.

I really hope Wingo can provide a manual tilling method (musca style), Thanks.
I'll be looking forward to it:)

dodo3773 · 2012-06-25 17:13:47

Does openbox-multihead contain the 2 newish patches that are in the repos openbox? Namely these two:

source=(
        
        movesize.patch
        title-matching.patch)

Or do I have to patch it myself if I wish to use this?

I looked at the PKGBUILD and I did not see any mention of these. Not sure if it is something you do upstream or not though.

Last edited by dodo3773 (2012-06-25 17:15:07)

BurntSushi · 2012-06-25 18:34:16

@dodo3773

Good catch, I didn't know about those patches. I've added them upstream and updated the AUR package.

Thanks!

dodo3773 · 2012-06-25 23:03:04

BurntSushi wrote:

@dodo3773
Good catch, I didn't know about those patches. I've added them upstream and updated the AUR package.
Thanks!

Awesome. Thanks. Will test soon. Been letting my second monitor go to waste for a long time now.

Arch Linux

#1 2011-08-11 22:13:04

Openbox Multihead (featuring per-monitor desktops) + pytyle3

#2 2011-08-11 22:21:04

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#3 2011-08-12 09:40:57

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#4 2011-08-12 13:46:38

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#5 2011-08-12 14:48:51

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#6 2011-08-16 14:28:01

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#7 2011-08-17 22:31:25

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#8 2011-09-08 20:25:00

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#9 2011-09-09 22:40:37

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#10 2011-09-10 14:19:58

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#11 2011-09-10 14:59:32

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#12 2011-09-10 15:04:00

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#13 2011-09-10 15:43:25

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#14 2011-09-27 18:40:27

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#15 2011-11-25 15:26:08

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#16 2012-01-17 12:55:27

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#17 2012-01-18 17:01:47

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#18 2012-05-12 02:33:50

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#19 2012-05-12 03:47:07

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#20 2012-05-12 04:31:27

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#21 2012-05-13 00:47:01

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#22 2012-06-11 15:48:41

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#23 2012-06-25 17:13:47

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#24 2012-06-25 18:34:16

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

#25 2012-06-25 23:03:04

Re: Openbox Multihead (featuring per-monitor desktops) + pytyle3

Board footer