tudurom
commented
5 years ago This was actually a bug, #51. You can now manage borders however you like. You can also have infinite borders with this tool and set them up using ruler and wew.
In addition, I had this neat idea of implementing infinite borders in windowchef and making them useful by making a simple event system comprised of events and states. The user then configures windowchef to change certain borders when certain events happen, or when a window's state is changed. An example event would be changing the group, and an example state would be the focused state.
Now the philosophy of windowchef is to be a minimal, yet highly functional window manager that lets the user build around it with external tools, effectively acting as the core of the user's highly customized environment, providing core features that can't be implementing as external tools, such as EWMH, ICCCM and very basic window manipulation (you could implement some of these using external tools, such as wmutils, but I consider this approach rather unnecessarily complex and wasteful). As a result, I think I will follow your approach. I will not implement such complex border manipulation routines in windowchef. Instead, I will let the user use tools such as wew, ruler and xprop -spy.
neyuki
While trying to work around this bug:
https://github.com/tudurom/windowchef/issues/38
I figured out that windowchef does not manage window borders on a per window/class/role/etc basis. Providing window borders either for all windows or for none doesn't seem to me to have enough utility to justify inclusion, especially in light of the above mentioned bug. I realize that that bug is probably the fault of Firefox, but buggy applications are a reality everyone has to live with, and there is no guarantee Firefox will ever even fix this bug. Additionally, it is confusing to users to have such inflexible borders in a window manager clearly designed to give users maximal control over their own window management. Windowchef should implement borders in a flexible way such that users have full control, or the window border code should simply be separated out into its own utility that allows users to set an arbitrary number of borders, control border colors on a per border basis, and do this all on a per window/class/role/etc basis. This latter might even be a superior option. If it is the case that such a utility would simply set all of these borders and then x11 would manage them with no need for further maintenance, then I would say that the latter option is definitely better. An example rulerrc could be provided allowing the user to have the nice 5 pixel border nearly out of the box, and it wouldn't be a huge leap for them to figure out how to adjust borders on a per window basis. Indeed, a workaround to enable Firefox to work correctly could even be provided as a commented example in the rulerrc. So as an added benefit, issue 38 would be solved by providing a workaround that would work for users until Firefox gets around to fixing its own bug. So it seems like splitting this off into a separate utility is probably the answer.