You are not logged in.

#26 2012-10-26 21:42:06

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

I set up a new IRC channel #wingo on FreeNode. Ping me if you need help.


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

#27 2012-10-28 10:24:35

guelfi
Member
From: /home/guelfi
Registered: 2011-07-01
Posts: 111

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Honestly, I find this window manager awesome, not even considering the fact that it's pure Go (which makes it even more awesome). I just have two small issues:

1. I can't seem to find a command which just sends a client to another workspace, but doesn't select the new workspace right away.

EDIT: nvm, WorkspaceSendClient does exactly that. Must have overlooked it.

2. For unknown reasons, I can't bind anything to Mod4-3. The event is not even "captured" by wingo; it's just redirected to the active window.

Last edited by guelfi (2012-10-28 10:26:04)

Offline

#28 2012-10-28 17:53:03

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

guelfi wrote:

Honestly, I find this window manager awesome, not even considering the fact that it's pure Go (which makes it even more awesome).

:-)

guelfi wrote:

2. For unknown reasons, I can't bind anything to Mod4-3. The event is not even "captured" by wingo; it's just redirected to the active window.

Whenever something weird like this is occurring, you should always check the log. And if it doesn't give a clear answer, you should definitely post the log so I can see it. :-)

To get ideal logging, you should use this to run Wingo

wingo -p 1 --log-level 3 > $HOME/wingo.log 2>&1

Of course, you can adjust where the log is saved.

I'm hoping that this is a simple solution where some other application you're running has already bound that key. If that's the case, there should be a warning in the log that will say something to that effect (but Wingo won't know which application has the key). However, this might not be true since the key presses are being sent to the active window...

So here are a few other questions to answer (but please do include the full log):

Does binding "Mod4-1", "Mod4-2", and "Mod4-4" work as expected?

Are you running Wingo in a desktop environment? If so, which one?


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

#29 2012-10-28 19:53:06

guelfi
Member
From: /home/guelfi
Registered: 2011-07-01
Posts: 111

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Mod4-1, Mod4-2 and Mod4-4 work. (I'm using them to switch workspaces). I already tried running the command manually and it works without problems.

I'm not running any desktop environment; I'm starting wingo directly from the .xinitrc.

I pasted the log at http://sprunge.us/dRJi, but it doesn't seem to contain anything related to it.

Last edited by guelfi (2012-10-28 19:53:38)

Offline

#30 2012-10-28 20:22:40

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Dang. Does "Mod1-3" or "Mod1-Mod4-3" work? (Mod1 is usually "alt".)

Also, could you post your `key.wini` file?

This is really perplexing. I'm going to try to come up with a simple program that tries to bind to Mod4-3 and hopefully reveals something.


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

#31 2012-10-28 21:03:43

guelfi
Member
From: /home/guelfi
Registered: 2011-07-01
Posts: 111

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Nope, these don't work either.

keys.wini: http://sprunge.us/ZShi

Offline

#32 2012-10-28 21:18:32

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

All right, let's try one more thing before I write a program for you. Thanks for sticking with me.

First, remove all of your "Mod1-{1, 2, 3, 4}" and "Mod4-{1, 2, 3, 4}" key bindings. Restart Wingo.

At a terminal, run:

xev > xev.log 2>&1

A new window should pop up. When that new window pops up, only press the following keys, in this order:

1
2
3
4
Mod1-1
Mod1-2
Mod1-3
Mod1-4
Mod4-1
Mod4-2
Mod4-3
Mod4-4

Then close the window.

Post your key.wini and the `xev.log` file. This will tell me exactly the kind of data X is getting when you issue Mod{1,4}-3.


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

#33 2012-10-28 21:23:17

guelfi
Member
From: /home/guelfi
Registered: 2011-07-01
Posts: 111

Re: Wingo: floating and tiling window manager with per-monitor workspaces

I already tried xev; it receives Mod4-3 even though it is bound. Full log at http://sprunge.us/gSDH.

There's probably a row of MotionNotify events because after I pressed Mod4-1 (which was not received by xev as it should be), the workspace changed and I had to focus the window again.

Last edited by guelfi (2012-10-28 21:23:58)

Offline

#34 2012-10-28 21:48:25

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

guelfi wrote:

I already tried xev; it receives Mod4-3 even though it is bound. Full log at http://sprunge.us/gSDH.

There's probably a row of MotionNotify events because after I pressed Mod4-1 (which was not received by xev as it should be), the workspace changed and I had to focus the window again.

Yeah, that's why I mentioned removing those keybindings from key.wini first.

But your xev.log gave me enough data. Unfortunately, everything appears normal. Gah. This is going to be a bugger, because I can't recreate the problem and don't see any obvious reasons why one particular key is failing.

I'll post back in a bit with a program that will attempt to do more debugging. Do you have a Go environment set up? (i.e., can I ask you to `go get ...` something, and have it do the right thing?)


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

#35 2012-10-28 22:20:54

guelfi
Member
From: /home/guelfi
Registered: 2011-07-01
Posts: 111

Re: Wingo: floating and tiling window manager with per-monitor workspaces

BurntSushi wrote:

Yeah, that's why I mentioned removing those keybindings from key.wini first.

Hmm, must have overlooked that.

BurntSushi wrote:

I'll post back in a bit with a program that will attempt to do more debugging. Do you have a Go environment set up? (i.e., can I ask you to `go get ...` something, and have it do the right thing?)

Yeah, I have a Go environment ready.

Offline

#36 2012-10-28 23:56:20

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

I'm really hoping this will tell me what's wrong. Since you already have a Go environment set up, run:

go get -u github.com/BurntSushi/xgbutil/_examples/keypress-english

Now, `keypress-english` should be in your $GOPATH/bin. Now run:

keypress-english --root

Note that this program will completely take over your keyboard. The only way to kill the program is to close the window with your mouse or press "Control-Escape".

Once the program is running, type in the same keys that you gave to xev:

1
2
3
4
Mod1-1
Mod1-2
Mod1-3
Mod1-4
Mod4-1
Mod4-2
Mod4-3
Mod4-4

Then post the output here.

This program is using precisely the same key translation as Wingo, so in theory, this output should show something weird for the Mod1-3 and Mod4-3 combinations. This is important because Wingo has its own X stack built from scratch, so it isn't using the same code that everything else uses to translate key presses (and unfortunately, translating keys is ridiculously complex).


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

#37 2012-10-29 00:48:00

Grinch
Member
Registered: 2010-11-07
Posts: 265

Re: Wingo: floating and tiling window manager with per-monitor workspaces

BurntSushi wrote:

For the one exception of the libraries that are available, using Go to write a window manager is a huge win on all accounts. (I had to write the entire X stack before I could write a window manager.)

Ahh, I now I remember where I've seen your name before (outside of Arch forums), you made the xgb package for Go which I read about on r/golang I think, great work! As for libraries/bindings it is quickly picking up it seems (much due to the efforts of kind souls like you) so hopefully that will be a problem of the past sooner rather than later. I was thinking about playing around with some game programming with Go and was happily surprised to see up to date sdl/opengl/glfw bindings available. Would be interesting to see a sdl/allegro/glfw type library built directly in Go, or why not a UI toolkit written in Go targeting X/wayland.

BurntSushi wrote:

Window managers don't need to be performant and they certainly don't require manual memory management, so that alone makes using Go more than feasible.

I suppose it's very much an issue of 'hurry up and wait...' when it comes to window managers, also although automatic garbage collecting generates undeniable overhead you can minimize it's impact by utilizing the same techniques one does with manual memory management when faced with performance constraints, like reusing memory blocks rather than releasing/(re)allocating (or in this case letting them be garbage collected) etc. Also IIRC Go's current garbage collector is a quite naive implementation so there should be room for improvement. Not that GC is in any way an issue for this project.

BTW wasn't there another tiling WM written in Go or did I imagine that?

BurntSushi wrote:

The commands in Wingo are defined by simple structs with Go's `reflect` package. Here's a simple example of a calculator, and here's where the Wingo commands are defined. Each struct defines the command name, the number of parameters and the types of each parameter. This makes error messages given to the user when they mess up really nice. Also, I can produce documentation for all of the Wingo commands automatically. Try `wingo-cmd --list-usage`.

Interesting and flexible solution, I'll be looking more at your code as studying practical code is always the best way to learn a language in my opinion. My experiences with Go are very limited as of now, I've done a round of tests to try and get a feel of the language, and my impressions would be as follows:

like:

the syntax - not surprising perhaps as I primarily write in c and python.
interfaces - nice solution and I guess it has no more performance overhead than a C++ virtual function?
go,channels - seems great at a glance but I haven't really done anything serious with them yet.

neutral:

automatic garbage collecting - it's nice to have but it comes with a cost which can be a nuisance.

dislike:

lack of union type - probably not a problem if you write exclusively in Go but if you want to use external C code union is quite often used. using runtime reflection to solve this must be very slow.

no implicit type conversion - always having to cast can get very tedious, I'd rather have warnings when I do crazy things smile

error on unused variables - warnings would do just fine in my opinion.

while the 'uppercase means exported' rule is ok, why is it that if I use: 'import . "foo" ' I can still only access the exported (uppercase) contents of foo, I thought using '.' as import name meant that the imported file shares your current package namespace. I'm probably being very nitpicky.

Anyway, overall I like what I've seen of Go, and with built-in concurrency primitives it seems well poised for the future as it's not as if we will have fewer cores to deal with in order to maximize performance come tomorrow.

Oh and I will give Wingo a spin soon aswell, still holding on to my openbox setup but I'm increasingly feeling like some old 'things were better in my days' fart for not embracing tiling wm's wink, and from what I gather Wingo strikes a good balance by offering both modes.

Offline

#38 2012-10-29 01:56:42

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Grinch wrote:

why not a UI toolkit written in Go targeting X/wayland.

UI toolkits are a ton of work. At least an order of magnitude more than a window manager. UI toolkits, in this day and age, and especially with Go, need to be cross platform. So you need an abstraction above at least three different backends (Windows, Mac and Linux). That alone is difficult.

Then you need to actually write the UI toolkit, the widgets, subscription mechanisms, etc., *and* be performant since there's so much graphics work going on.

skelterjohn has started this with go.uik. But it's not ready for even Alpha use, yet. (Last time I checked.)

Moreover, Wayland is another can of worms. I investigated a Go/Wayland library a few months ago, and the path is not easy. A pure Go implementation of the protocol would be a piece of cake, but it would be forced into software rendering. To do hardware rendering, you realistically need to use EGL. Unfortunately, EGL depends on libwayland, which is the C library. (It's a recursive dependency.) Which makes things extremely complicated---much more so than simply developing a wrapper binding to EGL like people have done already for OpenGL.

Grinch wrote:

I suppose it's very much an issue of 'hurry up and wait...' when it comes to window managers, also although automatic garbage collecting generates undeniable overhead you can minimize it's impact by utilizing the same techniques one does with manual memory management when faced with performance constraints, like reusing memory blocks rather than releasing/(re)allocating (or in this case letting them be garbage collected) etc. Also IIRC Go's current garbage collector is a quite naive implementation so there should be room for improvement. Not that GC is in any way an issue for this project.

Correct. The GC is a 100% convenience in Wingo. Pretty much no trade off.

I have used some of the techniques you've mentioned in research projects. Of particular note is a program that compresses all known protein sequences, which can use 64GB or more of memory. In this case, it's imperative to just do as little allocation as possible.

Grinch wrote:

BTW wasn't there another tiling WM written in Go or did I imagine that?

Yes. mdtwm. But it is even more unorthodox than Wingo. (It's a mouse-centric tiling wm.)

Grinch wrote:

interfaces - nice solution and I guess it has no more performance overhead than a C++ virtual function?

Fortunately, I do not know C++. From what I know, the overhead of a function call on an interface is very minimal. Russ Cox explains the implementation of interfaces in detail.

Grinch wrote:

go,channels - seems great at a glance but I haven't really done anything serious with them yet.

The XGB core is concurrently designed with goroutines and channels, and actually gets a performance boost from parallelism. It's really quite nice.

Also, Wingo's IPC mechanism runs in its own goroutine and dispatches commands into the main event loop. It was all very easy.

Grinch wrote:

automatic garbage collecting - it's nice to have but it comes with a cost which can be a nuisance.

Indeed, but a nuisance in a tiny subset of programs is a worthy price to pay. Garbage collection is a huge game changer. It affects APIs and the way you code. Also, in a language that emphasizes concurrency, GC is even more important---as maintaining a conception of ownership in concurrent programs is very complex.

Grinch wrote:

lack of union type - probably not a problem if you write exclusively in Go but if you want to use external C code union is quite often used. using runtime reflection to solve this must be very slow.

Many of the things you might use a union for in C can be accomplished by using interfaces in Go.

Also, if you really need to inspect the concrete type of an interface, you don't need reflection (or specifically, Go's `reflect` package). You can use a type switch or a type assertion. There is absolutely a performance penalty to pay for using such things though, but is only important in tight loops.

Grinch wrote:

no implicit type conversion - always having to cast can get very tedious, I'd rather have warnings when I do crazy things

Haha. Indeed, this is an old trade off. But Go interfaces and type embedding save you from a lot of type conversions that would otherwise be casts in C. (A lot of casts in C come from `void *`.)

Grinch wrote:

error on unused variables - warnings would do just fine in my opinion.

The Go compiler does not have warnings. This is to absolutely discourage the use of messy code. There have been a lot of debates about this, but the bottom line is that the Go authors are flexing their opinions here.

Grinch wrote:

while the 'uppercase means exported' rule is ok

It's more than OK! Once you start using Go, you'll see it. The cool thing is that the export rules of any particular identifier are encoded in the name itself. This means you know exactly which identifiers are exported/non-exported at every place it is called (and not just in its definition).

Grinch wrote:

why is it that if I use: 'import . "foo" ' I can still only access the exported (uppercase) contents of foo, I thought using '.' as import name meant that the imported file shares your current package namespace. I'm probably being very nitpicky.

The `import . "foo"` syntax is discouraged and not actively advertised. It is more a dev thing, as far as I know. It shouldn't be used. From the language specification: "If an explicit period (.) appears instead of a name, all the package's exported identifiers declared in that package's package block will be declared in the importing source file's file block and can be accessed without a qualifier." :-)

Grinch wrote:

Anyway, overall I like what I've seen of Go, and with built-in concurrency primitives it seems well poised for the future as it's not as if we will have fewer cores to deal with in order to maximize performance come tomorrow.

Yes! Although Wingo doesn't have a concurrent design, its underlying X library does. There are also a few select places where I use parallelism when available to speed up some operations (like image rendering). As a result, Wingo actually feels a bit snappier (under heavy load) when run in the presence of multiple cores.

Grinch wrote:

Oh and I will give Wingo a spin soon aswell, still holding on to my openbox setup but I'm increasingly feeling like some old 'things were better in my days' fart for not embracing tiling wm's , and from what I gather Wingo strikes a good balance by offering both modes.

The beauty of Wingo is that you can use it just like Openbox and blissfully ignore the tiling features. But maybe some day you decide to press that "Alt-a" key, and you'll discover what tiling is all about :-)


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

#39 2012-10-29 09:21:25

nperry
Member
From: Warminster, England
Registered: 2010-05-16
Posts: 85
Website

Re: Wingo: floating and tiling window manager with per-monitor workspaces

BurntSushi wrote:

Then post the output here.

work ~ $ keypress-english --root
WARNING: We are taking *complete* control of the root window. The only way out is to press 'Control + Escape' or to close the window with the mouse.
Program initialized. Start pressing keys!
Key: 1
Key: 2
Key: 3
Key: 4
Key: Alt_L
Key: mod1-1
Key: mod1-2
Key: mod1-3
Key: mod1-4
Key: Super_L
Key: mod4-1
Key: mod4-2
Key: mod4-3
Key: mod4-4
Key: Control_L
Key: control-Escape
Control-Escape detected. Quitting...

Looks find to me, as long as it isn't case sensitive.

Offline

#40 2012-10-29 15:30:53

guelfi
Member
From: /home/guelfi
Registered: 2011-07-01
Posts: 111

Re: Wingo: floating and tiling window manager with per-monitor workspaces

WARNING: We are taking *complete* control of the root window. The only way out is to press 'Control + Escape' or to close the window with the mouse.
Program initialized. Start pressing keys!
Key: 1
Key: 2
Key: 3
Key: 4
Key: Alt_L
Key: mod1-1
Key: Alt_L
Key: mod1-2
Key: Alt_L
Key: mod1-3
Key: Alt_L
Key: mod1-4
Key: Super_L
Key: mod4-1
Key: Super_L
Key: mod4-2
Key: Super_L
Key: mod4-3
Key: Super_L
Key: mod4-4
Key: Super_L
Key: mod4-Alt_L
Key: mod1-mod4-1
Key: Super_L
Key: mod4-Alt_L
Key: mod1-mod4-2
Key: Super_L
Key: mod4-Alt_L
Key: mod1-mod4-3
Key: Super_L
Key: mod4-Alt_L
Key: mod1-mod4-4
Key: Control_L
Key: control-Escape
Control-Escape detected. Quitting...

This is getting weird.

(As an additional bonus, I added mod1-mod4-1...4.)

Offline

#41 2012-10-29 17:44:28

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

All right. Could you guys run `xmodmap -pk` and post the output?


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

#42 2012-10-30 00:08:48

Grinch
Member
Registered: 2010-11-07
Posts: 265

Re: Wingo: floating and tiling window manager with per-monitor workspaces

BurntSushi wrote:

UI toolkits are a ton of work. At least an order of magnitude more than a window manager. UI toolkits, in this day and age, and especially with Go, need to be cross platform. So you need an abstraction above at least three different backends (Windows, Mac and Linux). That alone is difficult.

Indeed, that's why I'm hoping someone else would do it big_smile Didn't know there was something in the works (skelterjohn), interesting.

BurntSushi wrote:

Moreover, Wayland is another can of worms. I investigated a Go/Wayland library a few months ago, and the path is not easy. A pure Go implementation of the protocol would be a piece of cake, but it would be forced into software rendering. To do hardware rendering, you realistically need to use EGL. Unfortunately, EGL depends on libwayland, which is the C library. (It's a recursive dependency.) Which makes things extremely complicated

Sorry to hear that.

BurntSushi wrote:

Fortunately, I do not know C++.

Hah, you have indeed been spared tons of grief, keep it that way wink

BurntSushi wrote:

The Go compiler does not have warnings. This is to absolutely discourage the use of messy code.

That's just mean, there's no need to get 'personal' big_smile

BurntSushi wrote:

It's more than OK! Once you start using Go, you'll see it. The cool thing is that the export rules of any particular identifier are encoded in the name itself. This means you know exactly which identifiers are exported/non-exported at every place it is called (and not just in its definition).

Yes that's likely something which will become second nature very quickly, sure saves typing and keeps things ' cleaner' as there are no separate function declarations and no need to declare functions 'static' etc.

BurntSushi wrote:

The `import . "foo"` syntax is discouraged and not actively advertised. It is more a dev thing, as far as I know. It shouldn't be used.

Heh, leave it to me to pick up a bad habit in a language in no time at all wink  I mainly used it to easily share constants across packages without having to use the package prefix when accessing them. Also I should have rtfm which explains why it didn't work as I supposed it would.

BurntSushi wrote:

The beauty of Wingo is that you can use it just like Openbox and blissfully ignore the tiling features. But maybe some day you decide to press that "Alt-a" key, and you'll discover what tiling is all about :-)

Sounds great, baby steps is my melody smile

Thanks for the insight on Go from someone like you who actually uses it for a real project, very valuable.

Offline

#43 2013-04-26 10:10:38

Grinch
Member
Registered: 2010-11-07
Posts: 265

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Hey Burntsushi, I've been using Wingo for a while now and I really like it, great work! Anyway, I just convinced a buddy to install it aswell and he likes it aswell, but he did have a question if there was some option (either dynamically or through a default setting) to have the 'master' window to the right and the 'stack' on the left? I looked at the config files and I couldn't find any such option, is there one which I just missed?

Offline

#44 2013-04-29 01:52:02

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

@Grinch - I'm glad you like Wingo :-)

Unfortunately, there is no way to "mirror" the standard layouts in Wingo. I might add it this summer too. I'll report back on this thread if I do.


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

#45 2013-04-30 01:47:31

Grinch
Member
Registered: 2010-11-07
Posts: 265

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Well it's not a deal-breaker from what I gather, and given his past history of finding things to critique in everything (not even mona lisa gets a break) I'd say this being the only issue he found has to be a solid thumbs up ;D

Offline

#46 2013-04-30 02:21:55

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Awesome!

Drop by the IRC channel if you like: #wingo on FreeNode.


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

#47 2013-05-02 10:25:48

Grinch
Member
Registered: 2010-11-07
Posts: 265

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Ah, missed that there was a irc channel, I think I will.

Offline

#48 2013-07-04 04:46:13

Poplus
Member
Registered: 2012-02-10
Posts: 9

Re: Wingo: floating and tiling window manager with per-monitor workspaces

I started looking into wingo and realli liked it, it's the wm I was looking for big_smile
However, I can't find a way to make windows don't overlap my status bar (bash script + bar) hmm
Is there any way to tell wingo to leave a pad in the top of something similar?

Offline

#49 2013-07-05 16:57:33

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

Re: Wingo: floating and tiling window manager with per-monitor workspaces

Poplus wrote:

I started looking into wingo and realli liked it, it's the wm I was looking for big_smile
However, I can't find a way to make windows don't overlap my status bar (bash script + bar) hmm
Is there any way to tell wingo to leave a pad in the top of something similar?

Wingo reserves space for bars just like every other WM. The status bar should set struts and Wingo will detect those and allocate appropriate space on the screen.

It would help if you said which status bar program you were using and any relevant configuration details.

For example, if you're using `dzen2`, then you need to run it with `dzen2 -dock` at least to get it to set struts.


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

#50 2013-07-06 19:41:20

Poplus
Member
Registered: 2012-02-10
Posts: 9

Re: Wingo: floating and tiling window manager with per-monitor workspaces

I'm using bar and a simple bash script for testing

#!/bin/bash

function statusbar() {
        ws_list="$(wingo-cmd GetWorkspaceList)"
        ws_active="$(wingo-cmd GetWorkspace)"

        for ws in $ws_list; do
                if [ "$ws" == "$ws_active" ]; then
                        ws_all+="A-$ws "
                else
                        ws_all+="I-$ws "
                fi
        done
        date="$(date "%H:%M")"
        echo "$ws_all $date"
        unset ws_all
}
while true; do
        statusbar
done

on .xinitrc

statusbar | bar &
exec wingo --log-level 3 > $HOME/.config/wingo/wingo.log 2>&1

Last edited by Poplus (2013-07-06 19:42:15)

Offline

Board footer

Powered by FluxBB