https://github.com/gensss/tinywm-xcb-amd64
it's a 100% C->asm port of tinywm-xcb to learn how wm-s and xcb work

now im refactoring and extending it to be something like openbox

Very interesting project! I will follow it closely!

thx
its kinda fun to figure out and do

this repository on github won't change, it's just a port for an example
i'l make another repository when i think it's good enough to use daily
can't be thinking about making meaningful commits in this stage of development

meanwhile i could post the whole code here once in a while


note that the tinywm-xcb code has a few problems itself and i wouldn't recommend using it
mcwm is a better simple wm using xcb, but i found a couple things there that i (currently) think are wrong
http://hack.org/mc/projects/mcwm/

stardate -307583

added "click to raise window"

plan was to grab the left mouse click (to get mouse button 1 press events) and just use the the window that was clicked on to raise it
problem is when the button is grabbed the client window wont get those events
one solution is to replay the click to the client, like i seen now openbox does
that doesn't seem very efficient to me,
so i thought what id do was, I'd pretend I was one of those deaf-mutes
err, not that, id grab the mouse button only when it is outside of the focused window

but windows don't just send events
to get window enter/leave events every window has to be set to send those events (well, X has to be set)
that is done by getting an array of children of the root window and calling xcb_change_window_attributes on every one
(this will also be used when starting to draw decorations on every window and place them)

raising the window will mark it the focused_window
it will also be used for when i find out how to turn off X autofocus, hence the label

problem still exists as the first click, that raises/focuses the window won't get through to it
that can be fixed by replaying just that one click
don't know if that will cause problems later, but changing it to replying every click would be easy

When the window grab the mouse that means the program needs the mouse input, even when the mouse is outside the window. Raising other windows in this moment can cause incorrect work of the first program. So, the mouse click should be used for the WM functionality only if the mouse is not grabbed.

im grabbing only the mouse button
mouse pointer (motion) still gets passed to the "focused" window

now that you mention it i tried making a screenshot of a window using gimp and it worked (WM didn't get any events, funnily)
it may still fall apart if the window does something special (that a wm can't intercept)

just checked another thing, wm doesn't get events if a button is pressed (in windows focus) and moved outside of the window
if the button is released outside of the window, the wm gets a leave event

idk, openbox also grabs the mouse button 1, but it grabs it in synchronous mode
that means that openbox has to allow every click done to pass before X will continue to do anything
(xtruss is the tool used to debug, in a terminal in a Xephyr server)

things like raising all gimp windows when one of them is clicked on are afaik extensions

ofc, if i run across anything that can't be dealt with this way, il just rewrite the related parts

stardate today

setting keyboard input on one window turned out easy
just xcb_set_input_focus with XCB_INPUT_FOCUS_POINTER_ROOT and the chosen window will have focus
(openbox also calls xcb_get_input_focus at least 3 times, idk why 3)


for a quick window decoration i tried setting a border to the window
setting the thing is easy (xcb_change_window_attributes with XCB_CW_BORDER_PIXEL) but the border is broken
actually i'm not 100% on what is broken
the border acts as 1 pixel lines that can't be clicked on
so with a border set, a window at 0:0 with the size of the screen wouldn't get mouse events on the borders

with the current window move calculation the right and bottom border go off screen, but the top and left border don't
(pixel coordinates go from 0)

il have to draw window decorations anyway, so it doesn't matter really
just interesting design

AFAIK, all window managers for window decoration uses the reparent - i.e. the window manager creates a window and then makes the user window child of that window.

The decoration is drawn on the remaining area of the new parent window.

But I can be wrong. Didn't study the problem in details.

most of them do it like that, yes
mcwm, dwm, and probably many tiling WMs just set a border
il re-parent if there is enough benefit over borders plus moving all the decoration windows when moving the window

i'm still not 100% sure if the border is set how the window itself gets the (relative) pointer location
if it's the border is ignored (window_x/y + border_width = 0) then i can just adjust the position when moving/resizing/fullscreening

draw 3 n-pixel borders or set border, i think it would be same performance-wise
i'm actually leaning toward drawing so if anyone wants to write a pretty border drawing routine, they could


ofc X11 is not clearly documented, so experimenting is in order

i need a name for it

anybody got any suggestions ?

Well, in Linux world, there are traditions. It must be a negative and recursive!

I propose fint, which means "fint is not tinywm.

good tradition

i feel like it should have "wm" at the end
ftwm ? idk

this is the hardest decision yet
il just make a list and let ppl here choose


PS
i sat down with the goal of making the circle thing when you press the middle mouse button to scroll in firefox work
turns out setting input focus fixed that as well (and the menus and the list of links thing)

implemented basic alt+tab and keyboard shortcuts

keyboard keys are a... seem kind of complicated to do
il write more when i understand them fully

tabbing also wasn't simple
mcwm does it by remembering only mapped windows
but that becomes a problem when minimize/iconify and virtual desktops get involved
solution is to keep a list of all windows and mark currently mapped ones, then add another flag to mark if the window can be mapped at all

i also found out things about some programs
steam, for example, makes over 40 windows out of which most wont be mapped
thats ok by X but not for a wm
i guess i could cut out some of them, but il leave them just in case they actually do something


i think its stable enough now
so after a couple more things and some cleanup il upload it
though even after all the big features there will be plenty of details and some not-so-likely-but-possible race conditions

this also made me start seeing bugs in openbox
maybe ignorance is better since it is bliss

lots of talk and no code
https://github.com/gensss/wm_tmp
i needed to temporarily upload so i might as well post
(il make another for the real thing)

meanwhile
added fullscreen from the window hints (like when you press alt+enter in xterm or F11 in firefox)
that is part of ICCCM or EWMH, idk which one