**** BEGIN LOGGING AT Fri Jan 13 02:59:57 2012 Jan 13 04:34:05 did we ever fix the font bug? Jan 13 04:34:06 lol Jan 13 04:41:49 fixed no Jan 13 04:41:53 workaround yes Jan 13 05:40:49 hehe -> http://ompldr.org/vYzg4ZA/wterm_2012-13-01_003916.png Jan 13 05:40:54 wterm runnign cmatrix Jan 13 05:41:59 :D Jan 13 05:43:17 Brybry, i might easter egg that :D Jan 13 05:53:02 haha awesome, and i approve easter egg :P Jan 13 05:53:23 although probably low on the priority list :) Jan 13 05:54:42 you test 0.3.0 yet? Jan 13 05:57:00 lol bit twiddling power of 2, there was a reason that i didn't use that, hrm. oh well, if it works \o/ Jan 13 05:57:04 i haven't, is it in preware? Jan 13 05:57:11 i was just going through commits atm Jan 13 05:57:44 ya its in prewre Jan 13 05:57:56 I used postinst hack to avoid the font issue Jan 13 05:58:00 dtzWill, I wish I had the entire cup in the picture...using it as my avatar now. Jan 13 05:58:41 :D Jan 13 06:03:22 dtzWill: I'm gonna need help reworking the parser at some point Jan 13 06:03:37 ^^ anyone interested can help Jan 13 06:08:06 hmm Jan 13 06:08:45 cmatrix seems to crash wterm if you mess with fonts and term resizing Jan 13 06:12:04 we just need to fix the dang font stuff Jan 13 06:12:05 lol Jan 13 06:12:14 but good catch, crashing is no good :( Jan 13 06:12:28 its not font related Jan 13 06:12:37 its term size changes Jan 13 06:13:19 same thing happens if you rotate Jan 13 06:13:57 oh, okay. figured it was related, sorry :) Jan 13 06:14:12 dtzWill: I'm emerging shit on my desktop from wterm/ssh Jan 13 06:14:18 haha :D Jan 13 06:14:21 it is so wicked fast Jan 13 06:15:06 PuffTheMagic, Brybry: does the bluetooth keyboard use case work well yet? Jan 13 06:15:27 PuffTheMagic: :D very very glad. i've done no small amount of dev doing similar thing with xterm Jan 13 06:15:39 look forward to a pretty faster better equivalent :) Jan 13 06:15:45 haven't tried Jan 13 06:16:02 I left my bt kb 280miles away Jan 13 06:16:04 use case? Jan 13 06:16:15 i know brybry was poking at things like arrow keys (which are apparently different in plugin mode or something, he was saying?) as well as dismissable vkb Jan 13 06:16:35 Brybry: i just mean "if i was interested in using wterm with a bluetooth keyboard, is that a good user experience" Jan 13 06:16:39 I'll probably push my experimental branch up tonight with bt stuff Jan 13 06:16:57 it will be a good experience soon(TM) Jan 13 06:17:04 it's an ok one right now Jan 13 06:17:29 right now arrow keys don't work and you have to tap the terminal to set focus Jan 13 06:18:14 focus is easy Jan 13 06:18:22 focus was not easy ._. Jan 13 06:18:38 then again I don't really know enyo Jan 13 06:19:00 though the focus issue solves itself with autodetection of the bt keyboard and dismissing/hiding the vkb Jan 13 06:19:38 the only way I could manually get enyo to focus the plugin was to create fake click events on it =( Jan 13 06:19:50 eww Jan 13 06:19:58 there are better ways Jan 13 06:20:03 yeah, I didn't keep that around Jan 13 06:20:17 I tried a lot of different ways, couldn't figure out anything else Jan 13 06:22:11 Brybry, are you working on the BT keyboard for wTerm? Jan 13 06:22:20 yeah Jan 13 06:22:50 I will test as that is what is keeping me from using it. Jan 13 08:10:21 oooh, I think I figured out my focus issue Jan 13 08:12:33 tabIndex has to be set Jan 13 08:17:05 or allowKeyboardFocus: true Jan 13 17:06:48 just finished a new vkb layout Jan 13 17:08:33 http://ompldr.org/vYzhtbA/wterm_2012-13-01_120711.png Jan 13 17:08:38 ^^ thoughts? Jan 13 17:10:57 wb PuffTheMagic :) Jan 13 17:11:10 wb? Jan 13 17:11:14 welcome back? Jan 13 17:11:26 * PuffTheMagic didnt realize he left Jan 13 17:11:40 09:38 -!- PuffTheMagic [~PuffTheMa@unaffiliated/puffthemagic] has quit [Ping timeout: 240 seconds] Jan 13 17:11:43 :) Jan 13 17:11:48 stbuehler, this is all based on your layout work Jan 13 17:12:01 you said something didn't work Jan 13 17:12:04 rotating? Jan 13 17:12:19 i coudln't reproduce it, worked fine for me Jan 13 17:12:23 i think i know what the cause was there Jan 13 17:12:33 it had to do with upstream stuff that u haddent merged in yet Jan 13 17:13:09 i commented out all the vkb css Jan 13 17:13:17 and started fresh with the large layout Jan 13 17:13:25 using fixed widths instead of flex shit Jan 13 17:13:30 i have to make the small one now Jan 13 17:13:33 hm Jan 13 17:13:49 stbuehler, what i just said was unrelated to the rotation bug Jan 13 17:13:50 other layouts will need other sizes probably Jan 13 17:14:15 ok, so tell me more about the rotation bug :) how did you trigger it, what happened ? Jan 13 17:14:41 if I rotated into portrait and back to landscape the rshift got HUGE Jan 13 17:15:08 but like i said, i think that was cause of other bugs Jan 13 17:15:35 let me get what I have merged in with your base layout consolidation Jan 13 17:15:45 and then u can play with it more if u seriously want new layouts Jan 13 17:16:07 but i addressed what most people bitched about in this new layout Jan 13 17:16:19 tilde and ? are back in their default locations Jan 13 17:16:54 if people want bigger keys then they are gonna have to loose dedicated keys Jan 13 17:19:05 k Jan 13 17:19:45 i only put some of the key flex/width stuff in the css so you could use different values for large and small Jan 13 17:20:05 but perhaps this should be done another way to support other layouts that may need different sizes Jan 13 17:21:51 well you did help with issue 1 of the vkb, you got it down to 1 enyo kind instead of 2 Jan 13 17:22:00 which i wanted to do but was just too lazy Jan 13 17:22:06 :) Jan 13 17:35:13 PuffTheMagic: I like the non-split between , and . now and the better location for / Jan 13 17:35:30 does toLower only affect A-Z Jan 13 17:36:20 toLower shouldn't affect non-a-z Jan 13 17:36:33 what about < > ? Jan 13 17:36:37 shouldn't Jan 13 17:36:39 will it make them , . / Jan 13 17:36:42 k Jan 13 17:36:56 and neither should it :) Jan 13 17:37:22 there is a toLocaleLower in js afaik for things like Ä -> ä, Ö -> ö, Ü -> ü :) Jan 13 17:38:06 the only oddity worth mentioning with your kb is the dedicated pgup, but not pgdown, and del being on left Jan 13 17:38:41 that, and it seems like capslock could be repurposed for something ... maybe make it a ctrl key ;) Jan 13 17:39:52 a "windows" key :D Jan 13 17:39:52 I would do fn+left/right for home/end and fn+up/down for pgup/down Jan 13 17:39:54 those are possibilities Jan 13 17:39:59 stbuehler, i have windows/meta Jan 13 17:40:29 and where is "Alt Gr"? Jan 13 17:40:31 well, you already have double-shift for capslock, so it just seems duplicated, is all Jan 13 17:40:31 :) Jan 13 17:40:39 sconix, ya thats prob a better layout Jan 13 17:40:43 capslock doesn't even work for me Jan 13 17:40:48 sconix' Jan 13 17:40:54 s mapping matches the mac keyboards, I think Jan 13 17:40:57 dwc-, double shift is going away Jan 13 17:40:57 PuffTheMagic: at least for me that logical and something that does not require thinking Jan 13 17:41:08 all those visual locks are legacy from sdlterminal Jan 13 17:41:14 well, i think javascript should handle the modifier keys Jan 13 17:41:17 but i want to keep them around for the phone versions Jan 13 17:41:32 that would make it possible to change what is displayed too Jan 13 17:41:46 and layouts could do whatever they want Jan 13 17:42:14 then you could use the current pgup key for del/ins if nothing else Jan 13 17:42:55 sconix, for those bottom 6 i was thinking Jan 13 17:43:06 ins, pgup, del Jan 13 17:43:13 alt-gr or compose might be useful, but not to the majority Jan 13 17:43:14 home, pgdn, end Jan 13 17:43:27 ins home pgup Jan 13 17:43:29 del end pgdn Jan 13 17:43:35 I see Jan 13 17:43:41 you made it match a dedicated 6-key Jan 13 17:43:56 ya that is current layout Jan 13 17:44:01 PuffTheMagic: that would work even better I think Jan 13 17:44:06 but the way i just mentioned is how i've seen on many laptops Jan 13 17:44:13 yes Jan 13 17:44:32 yea, funny how those laptops make little use of half those keys Jan 13 17:45:44 http://i00.i.aliimg.com/photo/v0/258968004/IBM_Thinkpad_X30_X31_X32_laptop_Keyboard.jpg Jan 13 17:46:06 I kinda liked it with pgup/down on the far right, but pgup/down does make more sense on top of up/down Jan 13 17:48:38 why's double- going away, just out of curiousity? Jan 13 17:49:27 dwc-, well i suppose it could be an option, but that was pretty much only needed for the phones who didnt have keys like caps lock Jan 13 17:49:34 i want all the modifiers to behave like normal Jan 13 17:49:44 where u can press and hold them Jan 13 17:50:03 ahh... yea I noticed holding shift and typing 'ab' gave me 'ab' and not 'AB' Jan 13 18:10:35 stbuehler, new vkb code is pushed Jan 13 18:51:51 how does this look -> http://ompldr.org/vYzhveQ/wterm_2012-13-01_134940.png Jan 13 18:51:58 ignore the funkyness in the term area Jan 13 18:52:08 i just asking about the the keyboard Jan 13 18:54:13 i like it Jan 13 18:54:47 looks good to me Jan 13 18:54:48 had the same idea actually, just didn't implement anything :D Jan 13 18:55:44 now we only need some pics for some keys Jan 13 18:55:55 tab, shift, enter, ... Jan 13 18:56:07 working on that Jan 13 18:56:22 hm Jan 13 18:56:29 did you try html special chars? Jan 13 18:57:15 http://de.selfhtml.org/html/referenz/zeichen.htm#benannte_pfeile Jan 13 18:57:52 not sure whether the font will support them though Jan 13 19:03:49 looks ugly Jan 13 19:41:53 just about done Jan 13 19:58:03 http://ompldr.org/vYzhxOQ/wterm_2012-13-01_145709.png Jan 13 19:58:12 obviously the colors can be removed or changed Jan 13 19:58:15 i was just playing Jan 13 19:59:03 oil, pinger Jan 13 20:00:51 dwc-, stbuehler ^^ Jan 13 20:10:16 nice :) Jan 13 20:30:55 stbuehler, im thinking maybe instead of the colors, make everything but the letters a shade darker Jan 13 20:31:10 idk Jan 13 20:48:54 sconix, if wTerm had a non us keyboard, what keys would be replaced? Jan 13 20:49:25 s/replaced/changed based on default US kb/ Jan 13 20:50:01 so for me its enough to get after L, and after P Jan 13 20:50:10 sconix, or would having the Fn+ work Jan 13 20:50:48 for starters if FN + a = , FN + o = would work it would be enough for long time for me Jan 13 20:51:07 at least then it would make the keyboard fully usable for me Jan 13 20:51:20 sconix, thing is, the term area isnt uft-8 yet Jan 13 20:51:34 actually Jan 13 20:51:42 i forgot that I have more charsets I can use Jan 13 20:52:11 i might be able to make that work Jan 13 20:52:56 I would really appreaciate if you can get those work at some point Jan 13 20:53:02 well shit Jan 13 20:53:27 i could have the keyboard send those keys Jan 13 20:53:36 but u need apps to be able to send those as well Jan 13 20:54:48 actually most likely the only scenario I need them for is to be able to use irssi, so not sure if that requires the UTF-8 stuff to be working, but I can wait Jan 13 20:55:34 well terms to support these alternate character sets with out actually being utf-8 compliant Jan 13 20:56:22 jeah I guess, at least irssi you can configure so that it accepts other than utf8 as input Jan 13 20:57:46 hm, whatever input it supports, it really has to support displaying utf-8 characters Jan 13 20:58:39 right Jan 13 20:58:47 and we cant do that just yet Jan 13 21:02:32 ok, then I stay on hold for that one Jan 13 21:04:08 sconix, http://ompldr.org/vYzhyeg/wterm_2012-13-01_160255.png Jan 13 21:04:09 ;) Jan 13 21:04:37 PuffTheMagic: now find a place for ß :) Jan 13 21:04:48 oh, and € Jan 13 21:05:41 with combinations of the modifier keys we could probably add all those diacritics Jan 13 21:06:37 we would just need more fancyness on the vkb Jan 13 21:06:51 so that we could change what is shown on the keys when different modifiers are pressed Jan 13 21:07:06 yes Jan 13 21:07:21 did you move the key sym to terminal input handling to javascript? Jan 13 21:07:48 not yet Jan 13 21:07:59 the image was just me playing with the vkb css Jan 13 21:08:19 i need to improve the enyo kind for the keys Jan 13 21:08:39 instead of all this super ugly html content Jan 13 21:08:44 yep Jan 13 21:09:12 perhaps use arrays, and assign combinations of meta keys an index Jan 13 21:09:25 no meta: 0, shift: 1, ... Jan 13 21:09:59 one array for the displayed symbol. one for what is sent to the terminal? Jan 13 21:10:32 i'd just hate the webos source to drop in the next week or so Jan 13 21:14:51 dtzWill, yo! Jan 13 21:15:01 dtzWill, got thoughts on this Jan 13 21:15:12 dtzWill, seems like utf-8 support need to become a bigger priority Jan 13 21:16:45 stbuehler, so it seems like each key needs to support 4 characters to map all the diacritics properly Jan 13 21:17:00 i just dont know what sane keybindings should be for them Jan 13 21:17:15 fn and shit+fn obviously Jan 13 21:17:44 ctrl and alt already do things Jan 13 21:17:59 i guess I could swap around alt and meta on the kb Jan 13 21:18:13 that would give us Jan 13 21:18:18 on my german keyboard i use shift, altgr and ctrl for most things Jan 13 21:18:32 meta/altgr Jan 13 21:18:35 thought altgr+shift has special kkeys too Jan 13 21:18:38 though Jan 13 21:18:50 like |¦|¦|¦| Jan 13 21:19:00 well right now alt+ keys sends \x1b and then the key Jan 13 21:20:38 ctrl+ keys send ctrl + basically Jan 13 21:22:15 but then again, escape send \x1b Jan 13 21:22:22 so having alt do that is sorta redundant Jan 13 21:25:01 damn Jan 13 21:25:07 keys need to support 5 things Jan 13 21:28:07 grrrr Jan 13 21:28:14 so many characters Jan 13 21:30:30 so should I just not expect to handle all keys Jan 13 21:30:36 in 1 layout Jan 13 22:00:01 what some do is like, ctrl-' and then a vowel gives áéíóú Jan 13 22:01:04 so while germans might want the umlauts, the spanish would want the acute accents Jan 13 22:01:17 "dead keys" Jan 13 22:01:31 the french would want the graves as well Jan 13 22:01:42 °´`" Jan 13 22:02:02 it'd be really hard, I think, to support every keyboard layout Jan 13 22:02:09 dwc-, ctrl- is take up by vt compliance Jan 13 22:02:21 the germans would also prefer qwertz, I think and the french azerty too ;) Jan 13 22:02:35 supporting different layouts easy Jan 13 22:02:35 fn? Jan 13 22:02:50 supporting all possible keys on 1 layout, hard Jan 13 22:02:53 right Jan 13 22:03:12 im making the vkb code more flexible Jan 13 22:03:17 to support other layouts Jan 13 22:03:19 plus all the euro countries might want an easy way to get that too Jan 13 22:03:28 right Jan 13 22:03:31 sounds like you're going the right way Jan 13 22:03:38 once i get the base I will let people make custom layouts Jan 13 22:04:11 so, if you want just a base set, I think what you've got is really good Jan 13 22:04:53 we just need dtzWill to get in here and make the term support utf-8 Jan 13 22:06:29 release what you've got... if you're unlucky, the multi-byte thing will require a lot of internal changes :\ Jan 13 22:07:02 what I have is nothing Jan 13 22:07:07 wrt these custom keys Jan 13 22:07:28 the screenshot i showed was just visual Jan 13 22:15:27 ahh Jan 13 22:22:13 if (extTerminal == NULL || !extTerminal->isReady()) { extTerminal = this; } Jan 13 22:22:18 this looks crazy Jan 13 22:23:37 the "other" extTerminal is where you write the key events to, and "this", the SDLTerminal, is what receives the terminal output (if i got that part correctly) Jan 13 22:28:39 abstraction layer to enable swapping out the UI parts? Jan 13 22:36:17 the line buffer uses chars right now Jan 13 22:38:22 but the graphicsstate has two charsets, one for 0-127, and one for 128-255 - perhaps they can be used for utf8 Jan 13 22:42:50 thats what i was thinking at first but it wont work Jan 13 22:42:59 the app would need to switch to those charsets Jan 13 23:04:18 each charset has 128 chars Jan 13 23:04:29 you can define the mapping in lineDrawing Jan 13 23:04:47 so pick the unicode characters you want to support and add a mapping for them Jan 13 23:06:05 then you need to parse utf-8 chars in vtterminalstate.cpp:567 (right now it only reads single chars), and check whether they can be mapped. non "mappable" should be mapped to the same "box" symbol [] Jan 13 23:07:28 i would rather just do real utf-8 Jan 13 23:07:41 0-127 should probably always stay on the ascii map, and 128-255 should be used for the other charsets; depending on the mapping you would need a new graphicstate Jan 13 23:07:45 well Jan 13 23:08:11 i doubt anybody does that Jan 13 23:08:39 i bet most are Jan 13 23:08:53 but anyway Jan 13 23:08:53 http://ompldr.org/vYzh2aQ/wterm_2012-13-01_180738.png Jan 13 23:08:55 at least you should choose wisely for which ranges you want to cache the representation Jan 13 23:08:58 ignore the size of the keys Jan 13 23:09:08 as your texture would get very large otherwise Jan 13 23:09:16 111!!! Jan 13 23:09:39 so the vkb key supports an array of symbols Jan 13 23:09:42 up to max for Jan 13 23:09:46 and it auto lays them out as shown Jan 13 23:11:14 i started a german layout yesterday too, but got stuck in the sym->terminal thing :) Jan 13 23:17:29 with combinations of the modifier keys we could probably add all those diacritics <-- if you want support for that it's really easy Jan 13 23:20:40 basically this: https://github.com/Brybry/wTerm/commit/81110a37edd89082485b8bff449398f6d2551e69#L0R770 makes virtual key presses behave like real keys in SDL Jan 13 23:23:11 I've just had two things with it that I didn't like before it was ready: the change to the event loop for key repeating and handling card minimize (if you minimize the card you'll hit spacebar and it'll spam spacebar while minimized) Jan 13 23:54:53 Brybry, can u separate the fake key changes from the repeat changes Jan 13 23:55:17 probably Jan 13 23:55:22 stbuehler, i have the key/sym stuff worked out Jan 13 23:55:25 basically that function is how SDL privately handles key presses Jan 13 23:55:31 symbols is actually an array of arrays like u suggested Jan 13 23:56:02 symbols: [['A',97]] Jan 13 23:57:52 actually Jan 13 23:58:11 its [displaysym,sentsym] Jan 14 00:06:10 the new keyboard layout looks great PuffTheMagic (responding to http://ompldr.org/vYzhtbA/wterm_2012-13-01_120711.png ) Jan 14 00:07:08 oh and you kept working at it hhoray Jan 14 00:11:17 interesting idea stbuehler re:parsing utf8 and automatically setting the mapping Jan 14 00:12:21 i guess i'm unclear on how utf8 is "supposed" to work. to the internet-mobile, i suppose Jan 14 00:12:25 so that would mean only supporting a small portion of utf8? Jan 14 00:12:45 dtzWill, idk how terms do real utf-8 support Jan 14 00:13:05 but supporting charsets that go to arbitray utf8 characters is something i already added, we just need to define charsets that use them and logic to set the charsets Jan 14 00:13:28 i'm unclear how to make that interact nicely with the various terminal escape commands that set the charset slots Jan 14 00:13:29 dtzWill, but thats only 1/2 the issue Jan 14 00:13:44 turning key presses into utf8 is easy Jan 14 00:14:16 its the chars that come from the apps that could potentially break things Jan 14 00:14:34 taking a step back, why do we want "full utf8" support again? i'm not trolling or being difficult, i'm just wanting to identify the goal here... Jan 14 00:15:04 better support for international character sets? Jan 14 00:15:12 yes Jan 14 00:15:47 maybe terms abuse default charsets, idk Jan 14 00:16:39 if we could narrow things down from "support all the characters" that might be useful and i doubt anyone uses all of it Jan 14 00:16:44 or has a good use case for all of it Jan 14 00:17:23 hmm Jan 14 00:18:37 http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/utf8-plus-vt100.html is just something i found Jan 14 00:18:50 clears some of the mud out of my understanding Jan 14 00:23:07 whoa Jan 14 00:23:12 putty has seen some recent changes Jan 14 00:23:16 dtzWill, i personally dont have a use case for utf-8 b Jan 14 00:23:24 dtzWill, but sconix mentioned using irssi Jan 14 00:23:40 and idk how u can predict the chars that will be sent across on that Jan 14 00:23:58 you can't Jan 14 00:23:59 prob need more of his input here Jan 14 00:24:10 IRC has no charsets defined Jan 14 00:24:58 PuffTheMagic: yeah, i don't know. but i'm interested in understanding how this is done "in general" not just because chances are that there are engineering decisions that'd be useful to learn from but also because it seems the way a user interacts with their terminal in terms of "utf8" mode is complicated and diverse Jan 14 00:25:04 an irc channel or person talking could use whatever they wish, and there's no declaration of a charset anywhere Jan 14 00:26:51 dtzWill, maybe we just need to support ascii and all the latin-1 extentions Jan 14 00:27:05 so yeah my inclination is what you said PuffTheMagic, wait for input from users :) Jan 14 00:27:33 aupt service is now ready, needs bit of testing tomorrow but should not have any major problems Jan 14 00:27:41 make sure we do the simplest possible thing to make everyone happy :) Jan 14 00:27:50 PuffTheMagic: if so, that's easy-peasy :D Jan 14 00:28:36 but things like supporting japanese glyphs makes my head spin Jan 14 00:28:55 (very much not unrelated to my not understanding how that works on a computer to begin with) Jan 14 00:29:12 lol Jan 14 00:30:07 大変ですよ Jan 14 00:31:23 dwc-: are you illustrating the character-set freeness of IRC or actually typing question marks Jan 14 00:31:45 just dropping in some japanese glyphs Jan 14 00:31:49 i do know i have something misconfigured between irssi/screen/shell/terminal regarding support for some characters Jan 14 00:32:11 ah, haha Jan 14 00:32:27 PuffTheMagic: ? Jan 14 00:32:44 oil, i forget Jan 14 00:32:46 while agreeing with you about the difficulty of japanese glyphs Jan 14 00:32:50 ok Jan 14 00:32:58 oil, happy new year Jan 14 00:33:17 lol, its the 13th Jan 14 00:33:23 oil, u are never around Jan 14 00:33:39 im around Jan 14 00:34:02 oil's been ignoring you Jan 14 00:34:13 lurking Jan 14 00:37:50 oil, my question had to do with using css to insert an image Jan 14 00:37:55 i always fail at it Jan 14 00:38:21 make a div, set the background: url('something.png') center center no-repeat Jan 14 00:38:50 and the width/height at or above the image Jan 14 00:38:54 maybe it was the lack of center center no-repeat part that make it not show up Jan 14 00:39:52 and the path is relative to the css file Jan 14 00:39:57 right Jan 14 01:39:11 dtzWill, stbuehler ping Jan 14 01:43:08 http://ompldr.org/vYzh5OA/wterm_2012-13-01_204122.png Jan 14 01:43:30 mmmmmm Jan 14 01:43:32 me gusta Jan 14 01:43:37 are those the same key sizes as the existing? Jan 14 01:43:41 * dtzWill holds up touchpad next to screen Jan 14 01:43:56 things have changed a lil Jan 14 01:44:40 but this is with the new extensible layout format Jan 14 01:44:48 :D Jan 14 01:44:52 which should be able to support different locales Jan 14 01:45:05 and all keybindings can be on the js side now too Jan 14 01:47:11 Brybry, hate to tell u this, but it might be easier to implement the keyrepeat shit in js Jan 14 01:47:19 hmm? Jan 14 01:47:24 I did it in JS once Jan 14 01:47:25 esp if the modifier key processing is going to be in js Jan 14 01:47:50 just need to do a settimer really Jan 14 01:47:55 set timeout Jan 14 01:47:57 or what ever Jan 14 01:47:57 yup Jan 14 01:48:06 I have it up somewhere on github where I did it Jan 14 01:48:11 I think Jan 14 01:48:16 but I scrapped it and redid it in C Jan 14 01:48:32 it *works* in C it just needs to stop on app minimize Jan 14 01:49:10 * Brybry shrugs Jan 14 01:49:11 well to support more flexible keyboards and keybindings all the keystate stuff needs to be in js Jan 14 01:53:34 hmm Jan 14 02:00:16 but then i guess bt keyboard support might be harder Jan 14 02:05:30 looks like keybindings are gonna have to stay in the C code Jan 14 02:08:57 well, I dunno. Bt stuff could be easier then depending Jan 14 02:10:22 like if the JS side is handling all of the keybindings and such then it would basically be passing key presses straight to the terminal and so all C side stuff could handle normal keyboard input? Jan 14 02:16:47 PuffTheMagic: https://github.com/Brybry/wTerm/commit/1d1bb7b8a2e4c1df7fb71c9ff74fd346536c3026 Jan 14 02:16:49 take a look at that Jan 14 02:17:15 we don't have to use it or anything Jan 14 02:17:48 it doesn't actually *change* input behavior at the moment, it just makes virtual key presses track state/modifier state within SDL Jan 14 02:23:37 do a merge request for that would ya please? Jan 14 02:23:46 well, I dunno if we want to use it? Jan 14 02:24:00 and we might want to change it some Jan 14 02:24:26 i want to use it Jan 14 02:24:30 like if you hold down ctrl+shift+c the 'c' key picks up the shift and ctrl modifiers but if you were to say, tap ctrl+shft+c it would not Jan 14 02:24:30 it can always be changed Jan 14 02:24:36 yeah :) Jan 14 02:25:09 sent Jan 14 02:27:04 merged Jan 14 02:27:10 and im tweaking it to return the new modifier state Jan 14 02:27:18 so I can return that in the initial plugin call Jan 14 02:27:25 and update the vkb Jan 14 02:42:22 Brybry, that code does not seem exactly right Jan 14 02:42:37 it's a little backwards lol Jan 14 02:42:41 but it should be right Jan 14 02:42:54 the mod state is not tracking properly Jan 14 02:43:11 mod state definitely tracked for me Jan 14 02:43:21 hmm Jan 14 02:43:22 did u test with vkb Jan 14 02:43:26 yes Jan 14 02:43:37 only thing I tested it with as it only fires from that Jan 14 02:43:48 it never returns to 0 Jan 14 02:44:40 hmm, it does in my console Jan 14 02:44:41 like Jan 14 02:45:39 copy/paste from novaterm is the worst =( Jan 14 02:45:43 pull my master that i just pushed Jan 14 02:45:49 and u can see what I mean Jan 14 02:49:45 hmm Jan 14 02:53:28 I know it worked fine when I checked key modifiers from the SDLTermainl key event processing, I'll track it down **** ENDING LOGGING AT Sat Jan 14 02:59:57 2012