Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2013-05-22 17:17:10

Hey Trilby - I've noticed that lately--it's actually likely a month or more--I'm experiencing some funny behavior with my status.sh script. Every once in a while, I'll notice the time is off and when I check with htop, my status.sh is consuming close to 100% cpu and not updating--thus the time freeze. If I kill the status.sh while in htop, it shuts down alopex and I'm back to my xdm login.

I'm mostly noticing it after I run gnucash and then quit that application. It doesn't happen every time so I don't know how easy it will be to trace this or if it's something on my end.

I just noticed it now, again, while posting this but I won't kill status.sh until I finish posting. If it weren't for the time lag, I wouldn't notice this as the cpu status is frozen so doesn't show the high cpu useage and using luakit I didn't notice much slowdown.

edit: when everything is running normally, htop shows "/bin/sh /home/brian/bin/status.sh" running and updating. Every once in a while it shows "alopex /home/brian/bin/status.sh" and I did notice that it said that when it freezes and cpu goes high, but it doesn't freeze every time htop shows that running. Strange.

edit: I've been using the same status.sh since it was ttwm but I'll post it in case something is amiss

#! /bin/sh

while true; do

eval $(awk '/^cpu /{print "previdle=" $5 "; prevtotal=" $2+$3+$4+$5 }' /proc/stat); sleep 0.4
eval $(awk '/^cpu /{print "idle=" $5 "; total=" $2+$3+$4+$5 }' /proc/stat); intervaltotal=$((total-${prevtotal:-0}))
echo -n "{#3399FF}CPU:{#999999}$((100*( (intervaltotal) - ($idle-${previdle:-0}) ) / (intervaltotal) ))%:"
echo -n "$(awk '/MHz/ {printf "%.0f", $4}' /proc/cpuinfo)Mz "
echo -n "{#3399FF}RAM:{#999999}$(free -m | grep -i /cache | awk '{print$3}')Mb "
echo -n "{#3399FF}T:{#999999}$(($(cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp1_input) / 1000))C "
echo -n "{#3399FF}/:{#999999}$(df -h | sed -n 2p | awk '{print $3}') "
echo -n "{#3399FF}/home:{#999999}$(df -h /dev/sda6 | sed -n 2p | awk '{print $3}') "
date +'{#3399FF}%b %d {#FFFFFF}%l:%M%P'

sleep 5

done

Last edited by bgc1954 (2013-05-22 17:38:06)

HalosGhost · 2013-05-22 18:15:08

bgc1954 wrote:

Hey Trilby - I've noticed that lately--it's actually likely a month or more--I'm experiencing some funny behavior with my status.sh script. Every once in a while, I'll notice the time is off and when I check with htop, my status.sh is consuming close to 100% cpu and not updating--thus the time freeze. If I kill the status.sh while in htop, it shuts down alopex and I'm back to my xdm login.

Do `journalctl` or `dmesg` seem to have anything relevant to say?

All the best,

-Sam

bgc1954 · 2013-05-23 18:06:30

@ HG - it appears to be rather random and logs don't show anything relavent. It just happened a while ago and it was after using gnucash and then backing up my file to a floppy--now you know how ancient I am.

I then ran gnucash again and did a backup and it was fine this time, so I'm at a loss over what's happening.

Last edited by bgc1954 (2013-05-23 18:07:22)

Greduan · 2013-07-02 21:53:19

Very nice Trilby.

I tried it out using Xephyr, and I gotta say I love it.

I would switch to it in a heart beat (using awesome right now) if it weren't for the fact it doesn't have simple configuration files. It's gotta be configured at compile.

Perhaps make it possible to configure with an rc file (shell script). Or using another language (like how awesome uses Lua).

Otehr than that, keep up the great work.

Trilby · 2013-07-02 22:03:41

Thanks for the feedback Greduan.

It would actually be *very* easy to have an rc config file that is read at startup. But - to me - this only makes sense for programs for which configuration may have to change dynamically and/or take a long time to recompile.

The cost of a rc file is not in the difficulty coding or the amount of code it would take, but in the processing time it would take at every restart. I restart my WM *far* more often than I change the configuration, so having to reread (and 'reprocess') the config file every time seems wasteful.

While this is only my maniacally minimalist view that I don't expect others to accept, it is a view which I have set alopex to be committed to. There often is a desire to pull in the features that everyone else has - but if I made my window manager just like every other window manager, what place would it have in the community? Alopex may be defined as much by what it does not do as by what it does do - as another example, while there is some support for floating windows, alopex is not good with floaters. This too is by design: of course the intent is not to be bad at something, but rather to place the priority on being extremely efficient at doing a the things it is made to do well.

So that's a long way of saying a rc file will not be forthcoming - but I certainly welcome any other ideas on development directions.

Also, if you haven't checked it out, you can have a .alopex_conf.h in your home folder (or ~/.config/alopex/config.h) which will be used when you rebuild with the PKGBUILD. As recompiling should take no more time that restarting most WMs, this seems like a very good way to get ease of customization without requiring a re-parsing of a config file at every startup. If you like this, you can thank HalosGhost for driving that idea.

HalosGhost · 2013-07-02 22:11:24

Trilby wrote:

(or ~/.config/alopex/config.h)

Not to nit-pick, but Trilby's PKGBUILD actually pulls in from $XDG_CONFIG_HOME/alopex/config.h; which, is actually even better

All the best,

-HG

Greduan · 2013-07-02 22:20:03

Ah I see. Well I can totally understand your reasoning. I only restart my WM once per-day (when I start up the computer) or less (when I make it sleep during the night), sometimes more (when I'm configuring it), so I didn't think about it that way. But I do appreciate this ultra-minimalistic look into it.

I restart my WM *far* more often than I change the configuration, so having to reread (and 'reprocess') the config file every time seems wasteful. [...] So that's a long way of saying a rc file will not be forthcoming - but I certainly welcome any other ideas on development directions.

How about this then, it checks for an rc file, if it finds it it uses it, otherwise it uses the compiled config file.

That way users can go for the fast startups, or they can go for the easier configs, depending on their needs. that's just an idea though.

For example, the rc can be useful when you're playing around with it, so you can just restart and you have your new config, and check if you like it or not. If you like it you can then compile it, stuff like that.

Or, here's another idea, don't check by conditional, but rather by how it's called. If it's just called as `alopex` then it runs from compiled config. If it goes something like `alopex -c /path/to/config/file` then it runs it as a dynamic config file.

Alopex may be defined as much by what it does not do as by what it does do - as another example, while there is some support for floating windows, alopex is not good with floaters.

So it won't work as well as it could with stuff like Gimp? As an example of course.

Also, if you haven't checked it out, you can have a .alopex_conf.h in your home folder (or ~/.config/alopex/config.h) which will be used when you rebuild with the PKGBUILD. As recompiling should take no more time that restarting most WMs, this seems like a very good way to get ease of customization without requiring a re-parsing of a config file at every startup. If you like this, you can thank HalosGhost for driving that idea.

That is a good idea. So whenever it compiles it will check for this file and use this file instead? So whenever I do

sudo packer -S alopex-git

it will use this config file? sorry I'm lazy to re-compile manually each time.

Last edited by Greduan (2013-07-02 22:26:06)

Greduan · 2013-07-02 22:20:55

HalosGhost wrote:

Trilby wrote:
(or ~/.config/alopex/config.h)
Not to nit-pick, but Trilby's PKGBUILD actually pulls in from $XDG_CONFIG_HOME/alopex/config.h; which, is actually even better
All the best,
-HG

Thanks for clarification.

Last edited by Greduan (2013-07-02 22:26:41)

2ManyDogs · 2013-07-02 22:28:05

Trilby wrote:

So that's a long way of saying a rc file will not be forthcoming - but I certainly welcome any other ideas on development directions.

You have already added far more than I thought you would. I built the latest version and I hardly recognized it from the "old days" :-)

Please don't add a runtime config. There are plenty of other window managers that do this, and there are other people who share your "maniacally minimalist" views...

Last edited by 2ManyDogs (2013-07-02 22:32:13)

HalosGhost · 2013-07-02 22:35:07

Greduan wrote:

So it won't work as well as it could with stuff like Gimp? As an example of course.

It works fine for me, though I personally prefer to use GIMP in single-window mode.

That is a good idea. So whenever it compiles it will check for this file and use this file instead?

Yes, whenever it compiles (assuming you're building using the PKGBUILD—which I imagine packer does) it will use the custom configuration.

2ManyDogs wrote:

Please don't add a runtime config. There are plenty of other window managers that do this. There are other people who share your "manaically minimalist" views...

I think alopex sits at a very comfortable stage at the moment; there's very little more I'd want from it (maybe xft support )—I certainly wouldn't be too supportive of having a run-time configuration.

All the best,

-HG

Last edited by HalosGhost (2013-07-02 22:37:20)

Trilby · 2013-07-02 23:10:49

I also think it is pretty 'feature complete' now.

Which is almost sad - I like tinkering with it. But software bloat is like a cross between a zombie and a vampire. One must always have blowtorch and holy water at hand to fight of the temptation to throw in cool new things just because. I barely implemented the icons for this reason - but I think they are great and well worth the couple hundred of bytes of storage they may take up.

What might be a fun creative project that wouldn't infringe on alopex's minimalism is to hijack some of it's memory and allow a companion tool to not really rewrite a config file that has to be reread, but rewrite the variables in memory. This would *not* work for changing the statusbar font size, as the size of the status bar is calculated once at startup - but every other configuration variable could (in principle) be rewritten while alopex was running, and on the next retiling of windows all the new values would be used.

I say 'in principle' as writing to another processes memory is not a trivial (or necessarily safe) thing to do. Colors are easy, as the X11 graphic contexts are stored in the X server, and the program only gets a pointer to them. So I can pass that pointer to another program and access the graphic contexts just like they belonged to that other program.

I know shared memory can work in this way to - but I don't think 'regular' memory can.

Err ... wait, no. To do this with any variables other than those in the graphic contexts, the variables would all have to be declared as volatile. That would sacrifice all sorts of compiler optimizations.

Well, it was fun brainstorming for a moment.

I'm curious though what settings you would like more dynamic control of. For many settings, what is in the config.h is just the intial state and they can be changed at runtime with key bindings. This is already the case for visibility and placement of the status bar, the number of windows that should be visible in the stack and the tilebias. It would be pretty easy to make this available for gaps, borders too. What else would you want to be able to change?

As a related aside, I was previously thinking about allowing multiple configurations that could be toggled. This came up for me this summer while I had my computer with my out on a nice sunny day. I have a DayLight theme I've been working on which is *much* better for visibility in bright sunlight than my usual theme - and the way my terminal is launched, the theme applies through to the terminal as well. But as I was going in and out through the one nice week of summer we had here in MA, I kept switching back between WinterCoat and DayLight themes - to do so I had two compiled copies of alopex and a conditional check in my xinitrc. I thought it might be nice to have an "alternate colors" toggle for such occasions.

I'm really not sure if that be worth it in the grand scheme - probably not. What would be more realistic would be to have a function to do a data dump of the client list (with tag assignments, placements, etc) and execv another version (or a recompiled version) of alopex which could read in that data dump and pick up where the other left off. Essentially this would be a seemless transition from one version of alopex to another: all the client windows would stay in place.

With this you could change the config all you want, then recompiled,and "wmexec" with alopex probably in less time that it takes other WMs to read in their config files.

Anywhoo, that's just more brainstorming. I'm open to many of these ideas - and I'd love to add all sorts of useful features, as long as they can be done efficiently. Reading rc files is never really efficient.

Greduan · 2013-07-03 14:01:22

Oh I want to point out, I am a minimalistic freak like you, maybe not to your level but I like it when stuff is as small as possible.

I barely implemented the icons for this reason - but I think they are great and well worth the couple hundred of bytes of storage they may take up.

I also agree they're worth it. Just make them as compact and well compressed as possible.

I'm curious though what settings you would like more dynamic control of. For many settings, what is in the config.h is just the intial state and they can be changed at runtime with key bindings. This is already the case for visibility and placement of the status bar, the number of windows that should be visible in the stack and the tilebias. It would be pretty easy to make this available for gaps, borders too. What else would you want to be able to change?

Stuff that I would like to change after Alopex has been started... Well the colors mainly, I like tinkering with stuff a lot, so I often just change one variable or one little thing in a function and see how it works out. If it's too heavy to implement then you don't have to. Or if you don't want.

As a related aside, I was previously thinking about allowing multiple configurations that could be toggled.

Now you said it. A change of scenery is something that happens often with my environments.

-----

While we're at it, here's a feature request.

Since I have a small monitor I often work on almost-fullscreen mode, in DEs and stuff it would be called maximized windows. And I really appreciate tabs or task managers in this case. You know how they handle it in Windows, a little tab at the bottom minimizes or maximizes a window stuff like that.

Would it be possible to add this? It would be something simple like minimized windows aren't actually minimized, but actually moved to another tag or something like that.

Could that be added? Or can it be added as part of the config?

Trilby · 2013-07-03 14:14:59

I'm not sure I understand that last request.

You can move windows to other tags. You can also use monocle mode where only one 'maximized' window is visible and you switch between them with any of the window movement bindings (eg, Super+J Super+K in the defaults).

Greduan · 2013-07-03 14:30:30

Yeah I'm aware of monocle mode. Think about it this way, instead of super+j or super+k you use the mouse in the tab like window separation on the top. You see what I mean?

You know how it lists all the current applications on the top? As if they were tabs? Well what I mean is I would like to be able to click on those to switch between windows, instead of using super+j or super+k.

You see what I mean?

HalosGhost · 2013-07-03 14:36:34

Greduan wrote:

Yeah I'm aware of monocle mode. Think about it this way, instead of super+j or super+k you use the mouse in the tab like window separation on the top. You see what I mean?
You know how it lists all the current applications on the top? As if they were tabs? Well what I mean is I would like to be able to click on those to switch between windows, instead of using super+j or super+k.
You see what I mean?

This has been requested before. I know this isn't a democracy, but if I did get a vote, I'd vote against it. Alopex isn't very mouse-friendly (as Trilby has stated in the past), and I'm okay with that; in fact, I like it.

All the best,

-HG

Last edited by HalosGhost (2013-07-03 14:36:49)

Greduan · 2013-07-03 14:51:17

HalosGhost wrote:

Greduan wrote:
Yeah I'm aware of monocle mode. Think about it this way, instead of super+j or super+k you use the mouse in the tab like window separation on the top. You see what I mean?
You know how it lists all the current applications on the top? As if they were tabs? Well what I mean is I would like to be able to click on those to switch between windows, instead of using super+j or super+k.
You see what I mean?
This has been requested before. I know this isn't a democracy, but if I did get a vote, I'd vote against it. Alopex isn't very mouse-friendly (as Trilby has stated in the past), and I'm okay with that; in fact, I like it.
All the best,
-HG

I can totally respect that. I use Vim almost solely, that alone makes me almost a keyboard junkie.

This is just a nice to have feature, it would also make it a little more user friendly, not that that matters that much with stuff like this, but, you know, nice to have. sometimes I like to use the mouse for stuff.

Trilby · 2013-07-03 16:11:11

Greduan wrote:

instead ... use the mouse

Ah, yes, that's where you had lost me

Recognizing "clicks" at certain places in the status bar would actually take a good bit of code and several new data structures.

However, you can bind mouse actions. Mod+Button4/5/6/7 in the default bindings do some window movement and focusing. So if you were in a monocle layout - for example, then held Mod and used button 6/7 (left/right 'scroll' buttons) you'd switch focus to the next/previous windows.

This does require holding the Mod button - and I would be open to making mouse actions while the mouse is over the status bar 'imply' the Mod button. So instead of clicking the tab for a window, you'd just hover the mouse of the bar and 'scroll' to switch windows.

But this is about the extent that mouse-stuff would be practical.

Greduan · 2013-07-03 17:14:18

Ah I see. Well no problem. Again it's just nice to have.

Just a question, what are the plans for the documentation? Like how much do you think it'll take to finish writing it? Just cause I want to get into it.

Trilby · 2013-07-03 17:26:18

What's missing from the documentation? There are 3 great man pages and wiki page (both thanks to HG).

Last edited by Trilby (2013-07-03 17:27:25)

Greduan · 2013-07-03 17:46:12

Should have worded that better.

Note: As the manpages reach finalization, this page's information will be modified to reflect default settings and some clarification.

For some reason I read that and processed it as "documentation is still not finished". My brain sometimes thinks like that...

Are there any plans for an online documentation? It can still be in the manpage format, I just mean like an online version that I can see in my web browser.

Also thanks HG, for the documentation.

Last edited by Greduan (2013-07-03 17:46:38)

2ManyDogs · 2013-07-03 17:48:48

Greduan wrote:

Are there any plans for an online documentation?

Is the wiki not good enough? https://wiki.archlinux.org/index.php/Alopex

Greduan · 2013-07-03 17:50:00

2ManyDogs wrote:

Greduan wrote:
Are there any plans for an online documentation?
Is the wiki not good enough? https://wiki.archlinux.org/index.php/Alopex

Oh it's quite good. Although I mean the manpages documentation. In other words the full documentation that you can find in the man pages.

HalosGhost · 2013-07-03 17:52:21

Greduan wrote:

Note: As the manpages reach finalization, this page's information will be modified to reflect default settings and some clarification.
For some reason I read that and processed it as "documentation is still not finished". My brain sometimes thinks like that...

This misunderstanding is my fault. I added that note because I plan to pare down the information in the wiki so that it covers only the default settings and not elaborations of the features (as the man pages cover them, and that division makes more sense to me).

The documentation itself is essentially complete. As for an online version of the man pages, I don't think that necessarily makes a ton of sense given the state of the wiki, but if Trilby is interested in this, it takes very little work for me to generate the html files having completed the man pages.

All the best,

-HG

Trilby · 2013-07-03 18:42:40

You'd really prefer to read the man pages over the internet in a web browser than on your own computer? They are installed properly, just `man alopex`.

Please don't take this the wrong way - but while I'm open to suggestions, it seems like everything you want is just what alopex is not - so I'm not sure why it got your attention in the first place.

If you really wanted, you could use man2html on the man pages, then open them in a browser.

Last edited by Trilby (2013-07-03 18:43:53)

Greduan · 2013-07-03 19:22:40

Trilby wrote:

You'd really prefer to read the man pages over the internet in a web browser than on your own computer? They are installed properly, just `man alopex`.
Please don't take this the wrong way - but while I'm open to suggestions, it seems like everything you want is just what alopex is not - so I'm not sure why it got your attention in the first place.
If you really wanted, you could use man2html on the man pages, then open them in a browser.

Not gonna take it the wrong way.

And yes they are installed properly and they work fine, so it's not an issue of not being able to use it.

The reason is that online you can really get detailed. I am very used to having several tabs open, each one with all the stuff I need and just switch between them as needed. With man pages I don't have the freedom of tabs (at least I'm not aware that you can have tabs).

It's a matter of workflow really, I usually have a tab with the documentation, a tab with the code that works (in other words the default config file) and on the other side of the screen I have the actual code.

So yeah it's just a matter of workflow. Again, these are all just ideas, just suggestions.

so I'm not sure why it got your attention in the first place.

It just fits me the most. Light, open source (although most of them are), easy to use, and most importantly, fast.

Also the UI is what fits me the best, the rest just have something I can't put my finger on, that just makes it wrong for me.

Oh writing this from Alopex BTW. I gotta admit Alt+F4 takes a little bit of getting used to, I was used to Super+Shift+c but this is much better. Before Alopex I had forgotten of the Alt+F4 keybinding.

All of this stuff I'm saying are just suggestions, that even if it's a longshot, it's worth asking for.

-----

Oh HG, this is a suggestion for the documentation.

In front of each option in the man pages, could it be possible to include the kind of variable it should be? Take these variables for example:

static int tilebias = 0;
static const int attachmode = 1;
static int stackcount = 3;

If I didn't have the default config file as reference I would assume those should all have a const before the variable type. In fact I did assume that, since all of the first variables have it, until I noticed the difference. I went back and fixed stuff to how it should be after I noticed this.

So perhaps adding a little something to the documentation to point out this stuff might be useful. Of course this is only valuable if you're writing each value to a file manually, instead of copy&paste and modifying the values to your liking.

Last edited by Greduan (2013-07-03 19:28:50)

Arch Linux

#501 2013-05-22 17:17:10

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

#502 2013-05-22 18:15:08

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

#503 2013-05-23 18:06:30

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

#504 2013-07-02 21:53:19

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

#505 2013-07-02 22:03:41

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

#506 2013-07-02 22:11:24

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

#507 2013-07-02 22:20:03

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

#508 2013-07-02 22:20:55

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

#509 2013-07-02 22:28:05

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

#510 2013-07-02 22:35:07

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

#511 2013-07-02 23:10:49

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

#512 2013-07-03 14:01:22

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

#513 2013-07-03 14:14:59

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

#514 2013-07-03 14:30:30

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

#515 2013-07-03 14:36:34

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

#516 2013-07-03 14:51:17

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

#517 2013-07-03 16:11:11

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

#518 2013-07-03 17:14:18

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

#519 2013-07-03 17:26:18

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

#520 2013-07-03 17:46:12

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

#521 2013-07-03 17:48:48

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

#522 2013-07-03 17:50:00

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

#523 2013-07-03 17:52:21

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

#524 2013-07-03 18:42:40

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

#525 2013-07-03 19:22:40

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

Board footer