Commit Graph

1066 Commits

Author SHA1 Message Date
Pietro Gagliardi 0cc13633cb Added the tweets mentioned in one of the comments in area.go to the Area planning document. 2014-03-23 17:44:23 -04:00
Pietro Gagliardi 7acb3c5272 Added GDK_KEY_Alt_L/R to the modifier key handling in GTK+ key events. 2014-03-23 17:26:11 -04:00
Pietro Gagliardi aee2b98270 Fixed modifier keys in GTK+ not being registered by KeyEvent on first press. 2014-03-23 17:24:13 -04:00
Pietro Gagliardi d1376e035d Added the GTK+ implementation of Area keyboard events. Seems to work fine for now... 2014-03-23 17:12:30 -04:00
Pietro Gagliardi 646e91b25a Had ExtKey start at 1 so KeyEvent.ExtKey can be 0. 2014-03-23 17:08:46 -04:00
Pietro Gagliardi 234f88b535 Okay I'm done; fuck keyboards. 2014-03-23 13:03:01 -04:00
Pietro Gagliardi 58420cbb1c Update to previous commit 2014-03-23 12:12:36 -04:00
Pietro Gagliardi 963f83e39c Added loose ends to the Area keyboard planning. Hopefully I'll FINALLY write the code today... 2014-03-23 12:07:58 -04:00
Pietro Gagliardi bcd4de443c Added some Cocoa-related notes noticed when writing an input test. 2014-03-23 11:25:33 -04:00
Pietro Gagliardi 6ecf70bd3c Filled out the keyboard planning table in the Area planning document some more; it should be complete enough for ExtKey now. 2014-03-22 23:32:02 -04:00
Pietro Gagliardi c8d7d3a2a1 More Area key set planning. 2014-03-22 17:00:06 -04:00
Pietro Gagliardi 0eef9ba4bc Added a note about what package ui will do to a keypress it will not send out due to not being portable to the Area planning document. 2014-03-22 15:33:01 -04:00
Pietro Gagliardi 61a372987a Added GDK common keys to the Area planning document. This also filters out some of the Windows keys. 2014-03-22 15:30:39 -04:00
Pietro Gagliardi f06f0c5ab3 Added a list of Windows virtual key codes to the Area planning to start filtering the ones we can handle from the ones we can't; also expanded some other parts some more. 2014-03-22 13:25:03 -04:00
Pietro Gagliardi e73992ab71 Finally finished getting ready for Area keyboard input; now just need to figure out which keys to support. Also a Wayland-related TODO. 2014-03-22 12:30:58 -04:00
Pietro Gagliardi 18271980cb Finished writing what I need for the GTK+ key equivalency test: display of GDK_KEYMAP_A and GDK_KEYMAP_a to see if I can do what I want to do (map back). 2014-03-21 22:33:07 -04:00
Pietro Gagliardi d14aed4f47 Added code to the GTK+ Area to print the GdkKeymapKeys for a given key 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... 2014-03-21 17:06:46 -04:00
Pietro Gagliardi bf3a692b21 Added a note about OpenGL support on Linux (again) to controlcandidates.md now that I noticed it while looking for a way to test GTK+/Wayland... 2014-03-21 17:04:57 -04:00
Pietro Gagliardi 59cfaa3faa Whoops, also forgot about handling unwanted keystrokes in the final keyboard consensus in the Area planning document. 2014-03-21 14:59:50 -04:00
Pietro Gagliardi 2ff2cb6851 Whoops, forgot something in the previous commit. 2014-03-21 13:19:03 -04:00
Pietro Gagliardi 81670724e8 Reached a decision about Area keystroke handling; noted it in the planning document. I just now need to figure out one thing... 2014-03-21 13:17:08 -04:00
Pietro Gagliardi 88b8937c30 Er whoops, forgot one bit of info in the past two commits. 2014-03-20 12:14:30 -04:00
Pietro Gagliardi e517115556 Some fixups in the previous commit. 2014-03-20 12:11:56 -04:00
Pietro Gagliardi 9ea4b1280a Final say on character input woes in Area planning. 2014-03-20 12:10:30 -04:00
Pietro Gagliardi e7750f0235 More Area keyboard planning... 2014-03-20 11:25:29 -04:00
Pietro Gagliardi c766cb965f Added complementary GLib/GObject version compatibility macros to gtk_unix.h alongside the GDK/GTK+ ones. 2014-03-19 21:16:35 -04:00
Pietro Gagliardi 32112462f8 And whoops I forgot the most important thing: MY USE CASE (for keyboard input in Area planning again) 2014-03-19 17:47:47 -04:00
Pietro Gagliardi 04fa7cf20f Redid the whole Area keyboard event planning, with me coming to more of a definite decision... 2014-03-19 17:46:08 -04:00
Pietro Gagliardi 6447b65dfb Need to rewrite the keyboard planning section of the Area planning doc; added a bunch of links to help... 2014-03-19 12:21:06 -04:00
Pietro Gagliardi be90f38305 guh apple (keyCode not safe) 2014-03-18 23:37:35 -04:00
Pietro Gagliardi 8caf5823e3 Nope, getting rid of the lock on preferredSize() still doesn't let me go back to using channels for Area events. Oh well. 2014-03-18 21:44:46 -04:00
Pietro Gagliardi 901557e46a More Area keyboard planning. 2014-03-18 19:59:37 -04:00
Pietro Gagliardi 3873d1990a Added keyboard planning to the Area planning... oh boy. 2014-03-18 14:18:53 -04:00
Pietro Gagliardi 92dc282ffd Added the framework code for handling keyboard events in GTK+ Areas. Oh boy... this is gonna hurt (as I will describe shortly). 2014-03-18 12:44:21 -04:00
Pietro Gagliardi ac684b15a5 One last quick note in README. 2014-03-18 11:55:35 -04:00
Pietro Gagliardi c628c86597 Updated README with this decision. Also other documents as well. 2014-03-18 11:55:01 -04:00
Pietro Gagliardi 24342eb05d Restored the locks everywhere except on resizing calculations. I'll run under the assumption that uitask cannot process any requests while a resize occurs, which means preferredSize() and Stack/Grid.setRect() are inherently safe... let's hope I'm right... 2014-03-18 11:50:56 -04:00
Pietro Gagliardi b95d581e86 Update on my locking problem in the README. 2014-03-18 11:30:35 -04:00
Pietro Gagliardi 64d5eb541e Changed the new resizing code so that it uses the same allocated slice per window instead of making a new one to store all the resize requests each time. 2014-03-17 21:09:03 -04:00
Pietro Gagliardi c180703373 Er oh the crash was because I was still using the lock-friendly code. Will still apply the change to memory allocation because memory reuse. 2014-03-17 21:02:11 -04:00
Pietro Gagliardi 19227080da Changed window resizes so that the actual Control.setRect() functions appended to an array of requests that the resize() function set all at once instead of having each done individually. This will be necessary for what I think will be a solution to the deadlocks. It doesn't work right now; I'm assuming it's allocating too much memory. I know how to fix this, but I'm committing what I have so far to be safe. 2014-03-17 20:42:36 -04:00
Pietro Gagliardi c078266c6d Quick README fixup 2014-03-17 14:16:30 -04:00
Pietro Gagliardi e5425036e0 Put the Label that changed each second in the main test. 2014-03-17 14:14:29 -04:00
Pietro Gagliardi ad2208d370 Elaborated in the README. 2014-03-17 14:10:23 -04:00
Pietro Gagliardi 0e8680c04f Dumped the mutex locks from the other controls and elaborated/asked for help in the README. 2014-03-17 14:09:09 -04:00
Pietro Gagliardi bdb26046b6 Removed the areasnafu.md now that I have a solution... reverting back to the channel-based approach re-introduced the Paint deadlock, so it was still there all along. 2014-03-17 13:49:12 -04:00
Pietro Gagliardi 4adf1ae5cd Removed the mutexes from Labels and Areas because I'm at my wits end about settling the deadlock between window resizing and setting a Label's text. 2014-03-17 13:37:51 -04:00
Pietro Gagliardi 7c3647712b Updated the test program to the new AreaHandler interface. The deadlock still happens... just not so easily... so it's elsewhere... 2014-03-16 21:52:50 -04:00
Pietro Gagliardi ae554f10c3 Changed Area to use a delegate handler object that implements the new AreaHandler interface for handling events. Also updated the GTK+ backend with this change, and made a few more tweaks to the documentation in area.go. 2014-03-16 21:40:33 -04:00
Pietro Gagliardi ab4d286c78 Added a document explaining my Area woes. 2014-03-16 14:56:40 -04:00