Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2014-02-20 19:29:50

I believe I've found a pattern with wine applications. If it is the first app started after login, Diablo2 will start and run. If I first start a terminal, browser, etc., Diablo2 will kick me out of X when I start it.

I realized this after a pacman -Syu and wine was upgraded. When I tried to start Diablo2, the wine config window opened to update itself, and I got kicked out of alopex 4. Then I couldn't open winecfg in a terminal until I actually rebooted the system--I even tried logging out and using a different wm with no success, until the reboot.

Later on, I was checking email in chromium and when I went to try Diablo2, I got kicked out of X, but that time I was able to just logout and login and Diablo started and ran fine.

Last edited by bgc1954 (2014-02-20 19:31:27)

Trilby · 2014-03-20 20:53:14

I don't know how I missed this last post - that is very odd ... I'm not really sure where to go with that yet.

---

I came back to this thread to announce the recent major change. The vim-ish language I was hoping to make become too much trouble. But there is still an internal language (aloscript?) that is now much more "human readable".

The default config shows man examples. What it doesn't show is that many commands can be strung together with semicolon separators:

window 3 move top; exec urxvt -e htop; focus top

This (admitedly artificial) example will move the window at "mark 3" to the 'top' of the visible windows (into the master region). Then it will launch htop in urxvt. Then it will refocus on the window in the top position.

A slightly less useless example would be:

mark 3; exec urxvt -e htop; window 3 focus

This would assign the currently focused window to mark number 3, launch htop in urxvt, then refocus the window at mark 3 - in otherwords it will launch htop without removing focus from the currently focused window.

Documentation has yet to be written for all the available commands - but the default config should give an idea of all the basics.

Note that previous configs will not work (at all). All the changes, however, are in key bindings below line 90. So merging the tail end of the file should do.

Also, if it wasn't announced previously (or if it has been forgotten) these command strings can also be sent to the root window name (with xsetroot for example). Any root window name prefaced with "ALOPEX:" will be executed as a command string so third party tools or launcher menus can make alopex do what you wish.

Last edited by Trilby (2014-03-20 20:56:00)

bgc1954 · 2014-03-21 16:56:29

Trilby wrote:

I don't know how I missed this last post - that is very odd ... I'm not really sure where to go with that yet.

No problem, I just assumed you were very busy working at something else.

First, when I tried to use the new PKGBUILD and code, I was getting errors until I used the "options=(!zipman)" and then it would build and install.

The new keybindings worked out fine once I realized I needed to use "focus up, focus down" instead of "j, k", but I am having a problem with a keybinding for kill. It doesn't seem to work as I'm used to using alt+shift+q for quit, which works fine but alt+q for kill doesn't. This is a snippet of my config:

*.Bind.00.Key:                  q
*.Bind.00.First:                kill
*.Bind.00.Third:               quit

and yes I have changed my First and Third Mods to Alt and Alt+Shift--just what I'm used to.

I am also starting to think my wine problems are due to the nvidia-304-xx driver on my desktop as I can start a terminal or whatever on my netbook, using intel video, and then diablo will still work there. I'm going to try it on my T61 laptop and see if the intel video there makes any difference--I'll keep you informed. It's still odd that the old alopex doesn't have any issues with wine.

Trilby · 2014-03-21 19:17:18

Oops! That was just a silly error in the killclient function. It wasn't working at all unless a window was explicitly specified. This was due to my changing some of the logic in the actions.c file, but I forgot to update that function. I just pushed a fix for that one.

And as I have yet had no documentation or mention of how thes window marks work, one can assign any client window to a number 0-9 with the command (or a binding to the command) mark #. Marks 0 and 1 should not be used unless one is doing something very creative and ready for it to fail horribly as mark 1 is always the currently focused window, and mark 0 is always the previously focused window. Marks 2-9 are strictly for user marks.

The reason this fits with the above mentioned bug, is even without the just-pushed fix "window 1 kill" should still have worked as it would have explicitly specified the focused window as the target of the "kill" action. Without the new fix no default was specified - the new fix now defaults to the currently focused window if none is specified.

I know documentation for these commands is much needed. That is my next project.

Last edited by Trilby (2014-03-21 19:21:37)

bgc1954 · 2014-03-21 19:59:18

Trilby wrote:

Oops! That was just a silly error in the killclient function. It wasn't working at all unless a window was explicitly specified. This was due to my changing some of the logic in the actions.c file, but I forgot to update that function. I just pushed a fix for that one.

Yup, that fix works nicely. Thx Trilby.

bgc1954 · 2014-03-22 16:54:44

Just tried Diablo2 with wine on my T61 with Intel graphics. I put an Arch install on it just for me to play around with alongside the already installed Debian for my wife. Surprise, surprise, Diablo2 plays fine on the T61, so there seems to be something that alopex4 doesn't like about wine and the nvidia-304xx driver on my desktop. I can still play wine games on my desktop as long as they are the first and only app I launch.

I also just noticed that when I double clicked on a music file in pcmanfm, it opens with gnome-mplayer and I just get a big grey screen with no controls or menu--I end up closing it with my kill keybinding--which works fine now btw.

Trilby · 2014-03-22 20:32:28

I'll make a note of potential nvidia issues on the github readme. I'm not sure how to dif into that though as there is nothing in my code that explicitly uses any component of any video drivers. Alopex does rely pretty heavily on cairo for drawing - so if there is an issue at the cairo-nvidia level that's out of my hands.

As for the gnome-mplayer issue, that one is my responsibility. I wish it were the gtk3 dev's issue as gtk3 has essentially broken all backwards compatibility with basic X11 standards - but they're the big gorrilla, so they sit where they want and expect the rest of us to work around them. I did have a workaround in the previous version, I'll just have to figure out what it was.

Unia · 2014-03-22 21:16:28

^ I'm curious about that GTK3 issue. Can you share some links on the matter?

Trilby · 2014-03-22 22:14:35

Only when I find them again. I avoid gtk3 at all costs because it requires many work arounds. I don't even remember what I had to do with the previous version of alopex, so I have to dig it up again. I had related problems with many other programs interacting with gtk3 programs. Basically you are expected to use gtk3 library functions to interact with them, or some odd x11 workarounds as they ignore some of the ICCM standards.

Unia · 2014-03-22 22:42:09

I notice only one issue in DWM and that has to do something with the new client side decorations. As far as I know, Suckless is not a fan of these kind of workarounds either so I'm wondering what issues you were/are facing and if DWM has incorporated these workarounds..

Trilby · 2014-03-22 23:56:30

Unia wrote:

... so I'm wondering what issues you were/are facing ...

The issue is that gtk3 windows simply don't get drawn.

In iocane (another project) I found gtk3 winows also don't accept events sent via XSendEvent.

bgc1954 · 2014-03-23 17:17:41

I will confirm that there must be an issue with nvidia-304xx, wine and alopex4. I hadn't tried the nouveau driver for some time as it has always given poor performance for me in Diablo 2. I tried it out this morning and the game is quite playable and I can start and stop it as many times as I want, switch back and forth between wine apps and regular apps and didn't get kicked out of X even once.

That being said, nouveau isn't totally optimal for me as it does produce a lag in some games and others just won't play on nouveau. So until I get another video card, which isn't easy as it is an agp card and they aren't that easy to get, my options are sticking with alopex version2 or keep on using nouveau with alopex version4 and see if I can live with the consequences.

I still have to wonder, though, why wine apps will start and play on alopex 4 with nvidia-304xx as long as they are the first app started and then as long as you log out and back in again with xdm, you can still play another wine game. Odd...very odd. I might just settle for this option. It was an interesting exercise and I have a little more respect for the nouveau driver now.

Trilby · 2014-03-25 21:18:52

I just tried out gnome-mplayer and I get a similar result - though it is fixed by any action that causes a retiling (eg, moving windows, floating a window, changing tags, etc). Do you get the same result bgc?

If this is the case, I think I remember what the issue was: some programs (often gtk3) will not set their windows' sizes on creation, but instead they send a request to the window manager to resize their windows (which is silly). While silly, this could work if they did it properly and sent the map request for the window before the resize request (like firefox does) - but they don't do that, instead they send the size request for a window the window manager doesn't know about yet, *then* they send the map request.

I don't recall what the solution was, but if we can confirm that this is the problem (i.e. are your symptoms the same) then I can get cracking on a fix.

HalosGhost · 2014-03-25 21:47:58

Trilby wrote:

then I can get cracking on a fix.

Perhaps I'm misreading this, but wouldn't the easiest fix to be to offer a pull request upstream to fix the order of the requests it makes?

All the best,

-HG

Trilby · 2014-03-25 21:56:34

I'm pretty sure the gtk3 devs don't care about window managers other than gnome and relatives.

Related issues have come up before and the reports are ignored. They are creating a new protocol and ignoring the existing ones.

HalosGhost · 2014-03-25 23:05:20

Trilby wrote:

I'm pretty sure the gtk3 devs don't care about window managers other than gnome and relatives.
Related issues have come up before and the reports are ignored. They are creating a new protocol and ignoring the existing ones.

Well, that's a bummer.

All the best,

-HG

bgc1954 · 2014-03-26 00:21:49

Trilby wrote:

I don't recall what the solution was, but if we can confirm that this is the problem (i.e. are your symptoms the same) then I can get cracking on a fix.

Yes, that is the behavior I have as well. If you look back to my post #220, it looks like the same problem then--don't know what you did to fix it though.

Trilby · 2014-03-26 02:56:44

I think that helped track it down. I just pushed a potential fix - please let me know if it works on your end, it works for me.

bgc1954 · 2014-03-26 03:48:12

Works here too. Thx Trilby!

bgc1954 · 2014-04-10 03:56:49

Hey Trilby,

I'm finding that on starting alopex in Arch on my T61 Lenovo Thinkpad, intel graphics, I'm kicked back to my xdm login. I can get back in. no problem, on my second attempt. No .xsession-errors are apparent.

Also, I am getting blank status, tab status and tag status after starting firefox. I get a tab with no text and nothing to the right or left of the tab that is drawn. I've just noticed this recently so cannot zone in on what might have changed.

I haven't noticed this behavior on my netbook with intel graphics so I don't know where to go with this. Thoughts?

edit: I just found that my stat file is causing some problems in Arch. For some reason my cpu temp part of the stat has changed from /sys/classs/hwmon/hwmon0/temp1_input to /sys/class/hwmon/hwmono/device/temp1_input so alopex was kicking me out of X. I found this in an .xsession-errors file which hadn't shown this before. This must be some change in the kernel or somethng as I'm not seeing this in my Debian install on the same T61 laptop. What can I say?

edit: I am also noticing that on Arch the droid font is not rendering well on the T61. It seems thin and not as nice as on my netbook with intel graphics--t61 GM965/GL960 Integrated Graphics Controller whereas the netbook is an atom based intel graphics controller.

Last edited by bgc1954 (2014-04-10 05:11:22)

bgc1954 · 2014-04-16 03:27:26

Trilby,

I've found a font that looks good on my T61 with alopex ver 4. It's Roboto-Medium which is from the roboto pkg in AUR. I guess that it's just an individual preference which relates to your graphics card. Obviously cairo renders fonts differently on different graphics cards. I'm also noticing that I'm not getting blank status indicators with this font. I'm not so confident with cairo's rendering of things seeing as it doesn't seem to like wine on my old nvidia card and now my intel graphics with fonts on my lenovo T61...?

Trilby · 2014-04-16 14:49:06

Hmm - not sure what any of this could mean. Cairo doesn't really render the fonts, freetype2 does. However, cairo does put the freetype rendering onto the screen. The only thing that could come to my mind is if a font size is too small and/or the monitor resolution is low, the actual pixel width of any line of the font might round down to zero. I don't think this should be able to happen with antialiased fonts though. They might be ugly or unreadable if they are too small, but they should show up. But to test this, can you try modifying the font size?

bgc1954 · 2014-04-16 17:08:26

Trilby wrote:

Cairo doesn't really render the fonts, freetype2 does

Hey, what do I know?

I tried going to a size 12 from a 14, with droidsans, and they both look thin and raggedy. If I go to size 16 then the font looks smooth again, but it's a tad big for my liking. If I just use the aur roboto package size 14 displays nicely so I guess I'll just stick with that. My netbook uses the size 14 droidsans and it looks fine there so I'm guessing it's just a difference in the intel graphics between the two.

I am however still noticing that I'm getting kicked back to xdm on first login on the T61. I thought I had that straightened out by fixing my stat but it's doing it again and there are no erros apparent this time. I can log in fine the second time so I'm not quite sure whats going on now.

edit: I also just noticed that I got the blank tab/stat condition again on the T61. I went to use firefox and everything was fine while I had another tab opened for a terminal but when I closed that and just used firefox, the tab/stat area lost its text. I just see one tab and thats it. I have an .xsession error now but don't know if its relavent

(process:3804): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

I can replicate this condition every time if I just start firefox by itself and when it starts and after it's closed there is no indications on the tab/stat area. They don't come back until I logout and back in.I just went back to the T61 to check out something that popped into my head and now the firefox problem seems to be ok after the restart and the roboto font. Probably nothing to do with the font anyway.

edit: Just noticed that I got the blank tab/status again coincidentally when I went to your github site. I used firefox to check email, weather, etc. but when I went to the github site, I got the blank text and single tab display.

Last edited by bgc1954 (2014-04-18 03:24:16)

archlicious · 2015-06-02 22:58:24

Hello, I'm in love with Alopex but I'm struggling with some window rules - I would love to have either a panel or some dockapps on the right side of the desktop, and while I'm able to reserve the space needed, I just can't for my life figure out how to run the dockapps without being included in the tabs. I tried setting the window rules but they a) differ in the syntax in the config file vs wiki example, and b) setting the rules for the respective dockapps to floating doesn't do anything at all. What am I doing wrong? Here's a snipped from my config:

*.Rule.03.Name:				WMBlueCPU
*.Rule.03.Flags:			float

In an unrelated topic - focus follows mouse doesn't seem to work for me. I also would like to submit a suggestion for a close button on each tab and a way (if there isn't one already) to close floating, undecorated popup windows like those goddamn popup ads, or at least force them into a tab/tile so they're out of the way. Thanks ahead!

PS: I didn't realize that this thread hasn't been active for over a year. Sorry, didn't mean to wake the dead. But I still need an answer though, thanks.

Last edited by archlicious (2015-06-02 23:06:58)

Trilby · 2015-06-02 23:19:15

I'm glad you like Alopex. I haven't used it in a while myself, nor have I tinkered with the code in a while. So give me a bit to get my bearings again to help address these issues. The dockapps issue and the focusfollowmouse issue *should* both work - so if this is not simply a configuration issue, they can be considered bugs that I will work on soon(ish).

The wiki and the default config mismatch is likely due to different versions. Between major version updates (2 to 3) there was no backwards compatability. Alopex 3 was a completely new creation very different from version 2.

I will not implement buttons on tabs - it would be challenging and is fairly antithetical to what I intended for this WM to be. But your free to hack away at it if you want to try to make a patch.

The popups should be able to be closed in two ways: one with the default binding of Alt+F4 to close the window, or they can be forced into tiling by toggling tiling with a keybinding or with the Mod+MiddleMouseButton.

Overall no worries about "waking the dead" - I hope Alopex isn't dead, just resting But please be patient as I look into these issues (and while starting a new dayjob and moving this month).

Arch Linux

#701 2014-02-20 19:29:50

Re: Alopex: a tiling tagging tabbed window manager with fur

#702 2014-03-20 20:53:14

Re: Alopex: a tiling tagging tabbed window manager with fur

#703 2014-03-21 16:56:29

Re: Alopex: a tiling tagging tabbed window manager with fur

#704 2014-03-21 19:17:18

Re: Alopex: a tiling tagging tabbed window manager with fur

#705 2014-03-21 19:59:18

Re: Alopex: a tiling tagging tabbed window manager with fur

#706 2014-03-22 16:54:44

Re: Alopex: a tiling tagging tabbed window manager with fur

#707 2014-03-22 20:32:28

Re: Alopex: a tiling tagging tabbed window manager with fur

#708 2014-03-22 21:16:28

Re: Alopex: a tiling tagging tabbed window manager with fur

#709 2014-03-22 22:14:35

Re: Alopex: a tiling tagging tabbed window manager with fur

#710 2014-03-22 22:42:09

Re: Alopex: a tiling tagging tabbed window manager with fur

#711 2014-03-22 23:56:30

Re: Alopex: a tiling tagging tabbed window manager with fur

#712 2014-03-23 17:17:41

Re: Alopex: a tiling tagging tabbed window manager with fur

#713 2014-03-25 21:18:52

Re: Alopex: a tiling tagging tabbed window manager with fur

#714 2014-03-25 21:47:58

Re: Alopex: a tiling tagging tabbed window manager with fur

#715 2014-03-25 21:56:34

Re: Alopex: a tiling tagging tabbed window manager with fur

#716 2014-03-25 23:05:20

Re: Alopex: a tiling tagging tabbed window manager with fur

#717 2014-03-26 00:21:49

Re: Alopex: a tiling tagging tabbed window manager with fur

#718 2014-03-26 02:56:44

Re: Alopex: a tiling tagging tabbed window manager with fur

#719 2014-03-26 03:48:12

Re: Alopex: a tiling tagging tabbed window manager with fur

#720 2014-04-10 03:56:49

Re: Alopex: a tiling tagging tabbed window manager with fur

#721 2014-04-16 03:27:26

Re: Alopex: a tiling tagging tabbed window manager with fur

#722 2014-04-16 14:49:06

Re: Alopex: a tiling tagging tabbed window manager with fur

#723 2014-04-16 17:08:26

Re: Alopex: a tiling tagging tabbed window manager with fur

#724 2015-06-02 22:58:24

Re: Alopex: a tiling tagging tabbed window manager with fur

#725 2015-06-02 23:19:15

Re: Alopex: a tiling tagging tabbed window manager with fur

Board footer