harveyhunt / howm Goto Github PK

I wanted to do this a few months ago, but the lack of sudo in containers meant it was impossible to install packages - this has been worked around now. Select packages can be installed using a whitelist policy, I wonder if the obscure packages howm requires will be on that whitelist...

CENTER_FLOATING: Whether a window that has just been chaned to floating should be centered or not.

"chaned" should probably be "changed".

It's about time that howm had a logo. Perhaps something blocky and pixel like?

This was removed with the move to using cottage for commands.

By saving the IPC string of the last command, it should be possible to call ipc_process on the string to rerun the last command.

Howm gets into an infinite loop when kill_ws is used and wss[cw].current isn't correctly updated. If wss[cw].current becomes NULL then kill_client will return early, leading to an infinite loop.

This is the perfect task for a new comer - there are still quite a few comments that need updating and completing.

This is the case for when there is one or more clients (at least one of which is floating) and zoom is the current layout.

This has been requested by a lot of people and is something that should be added in the future.

For the first time you start howm, the dzen is script is blank and will not update unless there is any activity, like spawning a window. I think this should be easy to fix!

It would be great if we could get some unit testing into howm. I see two ways of doing it:

• Use minunit, a VERY lightweight unit testing lib.
• Compile howm into a .so and then use Python's great unit testing framework with the help of ctypes..

Opinions?

I think that it should be possible to ask howm information about its current state, such as layout, mode, config options etc.

This would also be helpful for querying information about clients, workspaces etc. Imagine being able to write a small program that can be used to search and then focus a given window.

A window may wish to be moved to a different workspace. This should be handled in client_message_event.

In order to do this, we need to be able to move an arbitrary client to a workspace. This can be achieved by factoring out the client {cutting,pasting} logic from op_{cut,paste} into their own functions.

_NET_WM_DESKTOP also needs to be added to ewmh_net_atoms.

Testing howm inside of howm is currently impossible.

A commandline option needs to be added so that a different socket can be specified.

I don't know whether it happens in other applications or not, but toggling fullscreen does cause a screen flickering and freeze on firefox.

It might be a nice idea to have a mode whereby windows can be selected that an operation will then be performed upon.

The selected windows could have a different border colour to the unselected ones?

There is no mention of cottage, sxhkd or how configuration now works.

I think it would be a nice idea to add external scripting to howm. This could either be done by reading from a FIFO (as is done in the dwm-fifo patch) or by creating bindings to another language (such as python).

At the moment I am leaning towards using a FIFO (I rather like the system used by cmus).

After some debugging, the following is true:

Ends up being that every client has the same value as head. Let c = head.

head == c
head->next == c
head->next->next == c
...

If you open two clients in horizontal layout you can switch the focus between them using OTHER_MOD + {jc/kc}.
However when you change the layout to vertical, the same keys are used to change the focus between them and not OTHER_MOD + {hc/lc} as per the vim motions.

Can you reproduce it @HarveyHunt

I think it is important for there to be an unsigned int within the workspace struct to keep track of the number of clients.

It would make op_cut and paste far easier, as well as reducing the amount of for loops (and therefore complexity and execution time) within the code.

• remove_client should take one away from the count
• create_client should add one to the count.

When doing "make debug" followed by "make install", latter step fails as it looks for the release path.

See: https://github.com/HarveyHunt/howm/blob/master/Makefile#L52

When opening 3 or more clients in any layout other than zoom, toggling the second window to floating will cause the layout to change to zoom.

This might be because of changes I have made to the code, or perhaps the required packages have changed.

Can someone on ubuntu please try to compile howm, after installing the packages in the .travis.yml

I think the time has come to move away from config.h, it is making refactoring howm into multiple files tricky, makes howm harder to package and requires that a compiler is installed.

I am thinking about using a bspwm style system, using cottage to send configuration, such as:

cottage conf workspaces 5

I am unsure what the best way to handle key bindings is - any ideas?

howm isn't a fast and responsive as I would like, optimisations need to be made.

A good example is when killing a workspace. remove_client refocuses all of the windows- that's rather wasteful.

I had this in my xinitrc
numlockx &
Which made sure that my numlock was on when I boot into my wm. This was causing my keys to do nothing in howm. Can somebody reproduce this bug?

Happens in the latest build on develop branch.

Maybe this will help newcomers. If I made any mistake, feel free to comment!

#!/bin/bash

# Create a named pipe for howm config output
ff="/tmp/howm.fifo"

# Create a logfile for howm log output
logfile="/home/harvey/.config/howm/log.txt"

# Create the pipe, if not existing
[[ -p $ff ]] || mkfifo -m 666 "$ff"

# Create a few workspaces and store them into an array
ws=("term" "vim" "www" "chat" "media")

# Mapping for layouts and the numbers that come from howm
lay=("▣" "▦" "▥" "▤")

# Set background color mappings
mbg=("#333333" "#5F5F87" "#AFD7AF")
# Set foreground color mappings
mfg=("#DDDDDD" "#333333" "#333333")

# Set background color for bar (dzen)
bg="#333333"

# Read howm pipe as howmout variable
while read -t 10 -r howmout || true; do
    # Check the output for a format that we can use
    if [[ $howmout =~ ^(([[:digit:]]+:)+[[:digit:]]+ ?)+$ ]]; then
        unset r
        # Read all needed howm output to seperate variables (seperated by :)
        IFS=':' read -r m l w s c <<< "$howmout"
        # Set the foreground color using the mappings
        r+='^fg('"${mfg[$m]}"')'
        # Set the background color using the mappings
        r+='^bg('"${mbg[$m]}"')'
        # Display the layout symbol for the current workspace
        r+=" ${lay[$l]} | "
        # Display the workspace name of the current workspace
        r+="${ws[$w - 1]}"
        # Brace expansion 
        r="${r%::*}"
    fi
    # Display the collected bar string and additionally the date on the right side
    printf "%s%s\n" "$r" " | $(date +"%F %R") "
# Pass those things to dzen and display it with specific height, background color, font and more
done < "$ff" | dzen2 -h 20 -y -20 -ta r -bg "$bg" -fn "Inconsolata-dz:size=10" &

# pass output to fifo
/usr/bin/howm -c ~/.config/howm/howmrc 1> "$ff" 2> "$logfile"

A lot has changed on the feature/ipc_config branch which means that the current docs are out of date.

Information needs adding about cottage, how sxhkd is used and how to configure howm.

An operator to repeat the last change made by howm?

Sending a floating cliento a corner doesn't take account of the gaps on the workspace.

In window managers like bspwm its possible to toggle to monocycle layout to only focus one window. Is there any support for this yet? I couldn't find it yet.

I really like i3's use of a scratchpad- a window that can be called up as a floating window, no matter which workspace you're on.

In regards to implementing this, I think that the best way is to store the client in a global variable and append the client to the end of a workspace's client list.

It would be cool if there would be an example of Lemonbar (https://github.com/LemonBoy/bar) instead of dzen2.

If you don't have the time I will try to figure it out for myself and post it once its working in a stable manner. 👍

I think having the ability to autostart applications and set properties about them (such as which workspace they are one, are they floating etc...) would be rather useful and simple to implement.

Hi hunt,

You've merged a good number of commits from the develop branch to the master one a while back (d810ad1). Perhaps it would be time for a new release? If so, a gpg signature for distro packaging would also be nice to have. :)

Cheers

Windows seem to behave weirdly - initially plain white with no content visible, appears on double click though.

Right clicking multiple times gives multiple context menus with none responding to mouse click.

I think that the time has come for howm to be split into multiple files. This will make testing, documenting and reading the code easier- it is something that I should have done a long time ago.

I don't have much time as I am starting back at university- does anyone else want to give this a try?

Note: A few months ago I began work on this, the work is in the refactor branch- but a lot has changed since then so be warned.

I think it is important for howm to have better mouse support. I don't like using the mouse with a tiling WM, but sometimes it is necessary.

We should support resizing and moving windows using the mouse.

Dzen2 can read it's configuration from .Xresources. It would be good to make use of it, it makes the config cleaner and improve understanding of what dzen is.

The cursor looks like a cross a lot of the time. This doesn't happen with other WMs.