| Age | Commit message (Collapse) | Author |
|
properly...
|
|
|
|
that need to be worked out before we can move on...
|
|
resize events, but since we're not handling scroll events, the scroll position won't change yet. (We're also not drawing with scrolling just yet.)
|
|
|
|
|
|
shut down. It will be used for drawing to Areas because using GDI itself is more complex than it needs to be.
|
|
|
|
to see the full details of the install.
|
|
multiarch-support again for testing
|
|
(this is why you test builds on all platforms, folks!) and added a TODO about resizing on Windows in the meantime.
|
|
|
|
outside the actual size of the widget. (I did notice this before.)
|
|
|
|
|
|
planning document.
|
|
|
|
|
|
for now...
|
|
|
|
|
|
|
|
the code today...
|
|
|
|
more; it should be complete enough for ExtKey now.
|
|
|
|
out due to not being portable to the Area planning document.
|
|
some of the Windows keys.
|
|
filtering the ones we can handle from the ones we can't; also expanded some other parts some more.
|
|
figure out which keys to support. Also a Wayland-related TODO.
|
|
GDK_KEYMAP_A and GDK_KEYMAP_a to see if I can do what I want to do (map back).
|
|
value. For GTK+/X11 it appears that we can just use the keyval field... that just leaves GTK+/Wayland (see previous commit). If the same applies, we'll need to see if I can feed artificial keycodes in and it'll still work as expected...
|
|
now that I noticed it while looking for a way to test GTK+/Wayland...
|
|
consensus in the Area planning document.
|
|
|
|
document. I just now need to figure out one thing...
|
|
|
|
|
|
|
|
|
|
alongside the GDK/GTK+ ones.
|
|
input in Area planning again)
|
|
definite decision...
|
|
added a bunch of links to help...
|
|
|
|
back to using channels for Area events. Oh well.
|
|
|
|
|
|
boy... this is gonna hurt (as I will describe shortly).
|
|
|