**** BEGIN LOGGING AT Thu Feb 09 02:59:57 2012 Feb 09 11:05:51 hm Feb 09 11:06:23 tried it too a little bit... i even managed to set the correct dimensions, but it still looks like crap Feb 09 13:12:36 perhaps calling PDL_SetOrientation would fix it? Feb 09 13:12:55 also on the device SDL exports a "SDL_WebOsHookSetOrientation" function Feb 09 13:45:09 stbuehler, Ben said rotation really wasnt fixed until 3.0 and that those fixed might have made it into 2.2 Feb 09 13:45:21 hm Feb 09 13:45:30 just wanted to open a thread in the forum :D Feb 09 13:45:33 im gonna see if these fixes is something we can emulate Feb 09 13:45:54 might even help to compare the SDL patch between 2.1 and 2.2 Feb 09 13:46:25 i'm not sure they actually published the "real" sdl sources they used Feb 09 13:48:19 sure they did Feb 09 13:49:39 i didn't find SDL_WebOsHookSetOrientation in the patch yet Feb 09 13:50:43 ah now. mc #fail Feb 09 13:58:40 SDL_WebOsHookRegisterActivateCallback SDL_WebOsHookRegisterPausedCallback might be interesting too Feb 09 14:01:04 we already use those Feb 09 14:02:29 really? i though we call setActive from enyo Feb 09 14:05:05 oh, i also like SDL_DelayWithEventInterrupt Feb 09 14:05:11 perhaps i can get rid of the timer thread Feb 09 14:12:14 i think it is the same patch for 2.1.2 and 2.2.0 Feb 09 14:16:17 oh nice Feb 09 14:16:48 up to 2.2.4: vfb->mem = (char*)SDL_malloc(vfb->pitch * vfb->pitch); Feb 09 14:16:57 in 3.0.5: vfb->mem = (char*)SDL_malloc(vfb->pitch * vfb->height); Feb 09 14:40:04 ohhh right Feb 09 14:40:17 the Pause/Activate stuff doesnt work on hybrids Feb 09 14:40:23 which is why I have setActive Feb 09 14:41:04 stbuehler, thin some LD_PRELOAD magic can work to change the SDL_malloc? Feb 09 15:12:42 stbuehler, just got another message from Ben Feb 09 15:13:04 me -> Are the fixes anything we could manually emulate in our code for 2.1? Feb 09 15:13:13 ben -> No, it involved resizing the communications buffer in RemoteAdapter for the different screen size. When I tested on 2.1, I remember that I'd lose communication with the plugin until I resized the object back to what it was before I started changing it. Feb 09 15:17:18 for the last stuck key bug: I can add a touchend listener to vkb and then stop propagation/bubbling of events that we handle in vkbKey Feb 09 15:17:27 I think that should do it Feb 09 15:25:43 so until RemoteAdapter is opensourced we need to block rotation on 2.1 devices Feb 09 15:27:50 sounds good to me Feb 09 15:36:15 should we force the orientation to be the usable orientation instead of startup orientation before starting the plugin? (like vertical instead of horizontal) Feb 09 15:43:36 force 'up' Feb 09 16:57:26 is there a way to remove the space between keys but keep everything the same visually? Feb 09 16:57:28 hmm Feb 09 17:04:20 bleh, I can tap the terminal area and a key at the same time and cause a stuck key Feb 09 17:13:08 destinal: does roast affect the efficiency of caffiene extraction? Feb 09 17:14:00 PuffTheMagic: no I think the caffeine is not really affected at all by degree of roast Feb 09 17:14:26 (in concentration present or how efficiently it can be extracted) Feb 09 17:15:58 PuffTheMagic: actually well I think it can *lose* caffeine with more roasting but the difference in percentage is very small like 5% Feb 09 17:17:28 Brybry: so whats the highest level kind we can use to catch all touchend events? Feb 09 17:17:42 I can put in wTermApp fine Feb 09 17:18:06 I'm just trying to think if it'll cause any performance hits down the line when we do mouse stuff Feb 09 17:18:17 destinal: see given a 3-4 min soak time, you would think it would be easier to get caffiene out of vienna vs city Feb 09 17:21:45 PuffTheMagic: well caffeine is very water soluble and will soak out of even green coffee (how it is sometimes decaffeinated) .. I think the loss at more roasting is the breaking down of the caffeine through whatever chemical changes take place during roast,.. the stuff I've read is inconsistent on it though, some say no loss, some say slight loss, but nothing indicates that it's any... Feb 09 17:21:46 ...easier to extract caffeine from roasted beans vs green at all Feb 09 17:25:24 PuffTheMagic: http://hackaday.com/2012/01/01/making-pure-caffeine-at-home/ note that he uses green coffee to extract the caffeine from in this method, doesn't even bother cooking the coffee (as it wouldn't help I think) Feb 09 17:32:18 PuffTheMagic: ok, if we can't fix the orientation in a live object, there is only one remaining solution :) creating a new object... Feb 09 17:33:04 stbuehler: didnt think about that Feb 09 17:34:56 it'll be nice if someday we don't have to compensate for 2.x and 1.x quirks :) Feb 09 17:36:00 destinal: so re: my roast question, just trying to figure out why that 1 bean gets me so wired Feb 09 17:37:26 creating a new object means we would need some service running that keeps the tty alive (we could pass the fd via unix socket pipes). but i don't think this is a real option here :) Feb 09 17:38:07 as long as it is possible to start in any orientation Feb 09 17:39:55 PuffTheMagic: hmm very good question Feb 09 17:40:47 stbuehler: ooooooooooooooooooooh Feb 09 17:41:22 stbuehler: each term window could have 2 plugins Feb 09 17:41:33 a video less component that manages the fd Feb 09 17:41:37 and the tty stuff Feb 09 17:41:41 and one that just does the rendering Feb 09 17:43:19 i'm not convinced this is a good idea :) Feb 09 17:43:35 services are nasty Feb 09 17:44:09 shared memory is ugly, and sending updates through a pipe... well, this is basically what tty handling is Feb 09 17:44:09 I can't even think of a usability case where one needs rotation on a phone Feb 09 17:44:24 you want to type in one orientation Feb 09 17:44:34 but sometimes want to view a document in the other Feb 09 17:44:59 i say we just ban that on 2.1 till the RemoteAdapter source is out Feb 09 17:45:08 which "might" come out with the webkit extentions Feb 09 17:45:14 well Feb 09 17:45:18 but might not come out till later Feb 09 17:45:29 if it is missing i'll just have to learn arm asm and use objdump... :) Feb 09 17:58:02 stbuehler: Brybry i changed my github username to RyanHope Feb 09 17:58:16 you are gonna have to update your .git/config Feb 09 18:09:04 I just thought about something Feb 09 18:09:08 I wonder if touchstart events can be bundled Feb 09 18:09:15 eww Feb 09 18:09:52 like if you tap two keys at the same time does one key ever not go down? Feb 09 18:12:50 nfc Feb 09 18:28:14 yup, they can Feb 09 18:36:48 easy enough to handle but I starting to feel like it would almost be better to handle all touchstart/end events at wTermApp level and then send them to the appropriate place Feb 09 18:36:56 I just worry about performance Feb 09 18:37:42 why would that be a performance issue? Feb 09 18:48:06 I think it would add slightly more overhead to every touch event/keypress instead of just slightly more to every bundled touch event/keypress Feb 09 18:48:19 I think I'll write it both ways and see Feb 09 18:48:32 i cant see how it is going to add anything Feb 09 18:48:56 i mean, if we are missing stuff then what we have is wrong Feb 09 18:49:17 and if the events werent bundled, then we would be doing more processing anyway Feb 09 19:06:49 it adds more overhead because you have to find the enyo object instance for every touch event's target element instead of just having it already due to enyo.bind Feb 09 20:21:45 Brybry: there is probably an easier way to find the enyo object Feb 09 20:22:39 * cryptk gets paid tonight... still no tax money though... Feb 09 20:22:43 i looked over the code a little but I didnt try an optimize it Feb 09 20:22:49 I think even hp enyo source does like enyo.$[elementid] Feb 09 20:24:13 hi guys :3 Feb 09 20:24:29 still studying enough that I can't really do anything useful, but missed y'all too much and figured lurking didn't hurt ;) Feb 09 20:32:48 hey Feb 09 20:33:26 Brybry: are you using something like that Feb 09 20:35:01 kinda sorta, in my original code I had a comment noting that it might be faster to do it that way, I wasn't sure (it didn't really matter because it was a function that was going to rarely get called) Feb 09 21:32:53 rwhitby: next time you talk with the HP/opensource people do you think you could inquire about RemoteAdapter and find out where on the release timeline that falls, Ben said hes pretty much doing only Enyo these days and doesnt know much about the plans for RemoteAdapter Feb 09 21:39:46 is RemoteAdapter different to BrowserAdapter? Feb 09 21:45:23 PuffTheMagic: BTW, have you done a wiki page with the list of OE packages that you require at each milestone to be able to use the stuff in that milestone? Feb 09 21:57:55 zz_rwhitby, yes I am pretty sure they are different, with out seeing the code I would guess that remoteadapter depends on browseradapter Feb 09 21:58:01 i guess i could ldd and find out Feb 09 21:58:19 * rwhitby wonders how to stop ZNC doing the zz_rwhitby thing Feb 09 21:58:53 rwhitby, and no, no wiki page like that since most of the milestone descriptions are fairly vague, not sure what they actually provide Feb 09 21:59:09 rwhitby, zz_ is some sort of auto-away nick Feb 09 21:59:30 PuffTheMagic: you've got it round the wrong way - my suggestion is for you to define what you want from each milestone and drive that into HP's planning Feb 09 21:59:55 rwhitby, there should be an away option you uncheck for that Feb 09 22:01:12 thats what I do for znc, since otherwise it would constantly change as my laptop jumps wifi points. Feb 09 22:01:42 rwhitby, i certainly can take that approach, i guess first step would be defining libs and app that should fit into each of the milestone categories Feb 09 22:02:00 im sure destinal and others would want to have input on that too Feb 09 22:02:26 PuffTheMagic: I believe they have already started on it Feb 09 22:03:07 u know we have talked about it unofficially, and there is the wish list Feb 09 22:03:30 i wasnt aware of any efforts to define explicitly what each milestone should be comprised of Feb 09 22:05:16 PuffTheMagic: oh we have started work on a google spreadsheet since wiki wasn't as rapidly collaborative Feb 09 22:05:28 I wonder how I can open it up to anyone\ Feb 09 22:05:41 google doc? Feb 09 22:06:28 PuffTheMagic: https://github.com/Brybry/wTerm/commit/b7491f6ff4b16ae02b1d7d0d4b10442834dcd929 and https://github.com/Brybry/wTerm/commit/ec550f373d9903324b450ded7dc6c1e518801884 Feb 09 22:07:33 first way is basically how we do it right now but extended to catch lost events at wTermApp level and second way is a rewrite/catching all touchevents at wTermApp level Feb 09 22:08:15 and everything still works fine for plugin touchevents either way Feb 09 22:08:34 PuffTheMagic: https://docs.google.com/spreadsheet/ccc?key=0AmdfWb13hoeRdGdrMEY3MjB2aktjbjBxSHVMQ0dtaEE Feb 09 22:08:55 oh, minus a small bug Feb 09 22:08:57 * Brybry fixes that Feb 09 22:09:27 PuffTheMagic: it's not quite proper at this point, milestone should be one of the months / milestone names palm put in their roadmap that we think that package should be released during Feb 09 22:09:35 err HP Feb 09 22:11:10 destinal, so that is a dump of ipkg installed? Feb 09 22:11:25 PuffTheMagic: yeah from topaz Feb 09 22:20:40 Brybry, getEnyoObjectFromElement() looks like overkill Feb 09 22:21:44 Brybry, and instead of looking for handleDownEvent cant you check to see if its a vkbKey or something Feb 09 22:22:28 well, the problem is that touchend gives you an HTMLElement which could be like, the image in the enter key Feb 09 22:22:31 Brybry, i could also set nodeTag in vkbKey Feb 09 22:22:35 and the parent of that will be a vkbKey_control Feb 09 22:22:37 then instead of type === 'object' Feb 09 22:22:41 and what you really want is the vkbKey Feb 09 22:22:42 it would be what ever we want Feb 09 22:23:05 it can be tweaked however though Feb 09 22:23:11 I made the rewrite very broad/extendable Feb 09 22:24:27 so that it could kind of act like how the enyo foobartHandler() functions work, you just add on to whatever you want to handle touch events Feb 09 22:24:36 making it vkbKey specific is fine too though Feb 09 22:24:52 well u were worried about overhead before Feb 09 22:25:41 I don't think that changes the overhead at all =x Feb 09 22:26:15 well, unless hmm Feb 09 22:26:20 well if u cut out some of those unneeded checks Feb 09 22:26:22 I could throw out getEnyoObject by property with that Feb 09 22:26:37 and make it go up html objects until it finds an enyo object that is also a vkbkey Feb 09 22:28:05 you dont like the iead of setting the nodeTag field to something other than object? Feb 09 22:28:56 not sure if that would break anything or not Feb 09 22:29:07 actually it might Feb 09 22:29:14 prob needs to stay its default div Feb 09 22:33:44 I don't really know what setting the nodeTag would do Feb 09 22:33:50 or how it helps Feb 09 22:41:20 PuffTheMagic: https://github.com/Brybry/wTerm/commit/c5600271e73f5f1134c4d71bfdd1f2e7bbf21a1c Feb 09 22:45:46 PuffTheMagic: you know that SDL_USEREVENT is or event.type, not event.user.code, right? Feb 09 22:46:04 ah Feb 09 22:46:04 hm Feb 09 22:46:11 snd commit changed it again Feb 09 22:46:45 exactly why i didn't like that SDL_USEREVENT stuff and put the async queue around it Feb 09 22:47:34 PuffTheMagic: so why use 2 event types? Feb 09 22:48:10 the special handling for internal events was on purpose Feb 09 22:52:15 and debugging stuff as LOG_ERR Feb 09 22:54:45 may i ask you to revert those commits? i don't see any point in those changes :( Feb 09 23:16:51 PuffTheMagic: we need to port this chording on screen kbd to webos http://www.geek.com/articles/mobile/one-handed-keyboard-now-available-for-touchscreens-2012029/ Feb 09 23:19:39 stbuehler, all i did was move it from using event.use.code to event.type Feb 09 23:20:16 PuffTheMagic: yes, and made the constants public. for an internal event. and you know that event.type is very limited in the range? Feb 09 23:20:29 i just don't see "why" Feb 09 23:20:33 finding a short throw projector that does 1080p is almost impossible... Feb 09 23:21:18 as event.type is used in bitmasks in 32-bit integers, event.type < 32. user events start at 24... Feb 09 23:23:01 stbuehler, you are are worried about using up 255 userevent slots? Feb 09 23:23:42 no. 8 slots. Feb 09 23:26:53 those commits are now gone, back to mysterious event int codes Feb 09 23:27:24 well, i have no problem with a private enum (or #defines) in the .cpp file to have sane names for those numbers Feb 09 23:27:48 i just didn't see a reason to split the event types and making them public Feb 09 23:29:00 my idea was, that the internal usage of this event doesn't care about "extra" events Feb 09 23:29:13 so you can't break anything with sending such events Feb 09 23:29:44 and i'd like to use async jobs, as they are more flexible in what data they care and still type safe Feb 09 23:31:35 s/care/carry/ Feb 09 23:38:09 stbuehler, that was part 1 of someting i didnt commit Feb 09 23:38:22 i added another event in there that i need in terminal_main Feb 09 23:38:29 which required it be public Feb 09 23:38:45 jhojho, you see this http://youtu.be/KfOEJ-HZ1-Q Feb 09 23:40:44 i guess the custom videoresize event isn't needed now anyway (and i think the real resize event could be used for that too) Feb 09 23:41:12 and as i said, i'd like to use async jobs instead for custom events, if you are unsure how to use them just ask :) Feb 09 23:46:59 Brybry, looks good Feb 09 23:47:01 push it Feb 09 23:48:04 stbuehler, i want to get 0.4.0 out the door, so im gonna lock the rotation on 2.1 for now Feb 09 23:48:16 feel free to investigate the new object idea when you want Feb 09 23:51:30 just lock it :) i don't see a fix coming soon Feb 09 23:51:39 Brybry, get that pushed so I can tag 0.4.0, its been beta long enough Feb 09 23:52:40 dtzWill, oh while u were gone i added you, Brybry and stbuehler as contributors on my repo so u can push directly to it Feb 09 23:52:46 somehow my cat shorts out my desktop or something ._. Feb 09 23:58:50 is your power cord like... not connected all the way Feb 10 00:00:47 Brybry, like my debug output? http://ompldr.org/vY3FiNg/debug.png Feb 10 00:01:10 oO Feb 10 00:01:35 no, he like rubs against the front (power buttons are on top) and it magically locks up Feb 10 00:01:39 he's done it twice today Feb 10 00:02:08 :D Feb 10 00:02:24 PuffTheMagic: is it possible to get the current orientation and lock on that instead of "up" ? Feb 10 00:02:29 best debugging output ever Feb 10 00:03:02 stbuehler, possible yes, do i want to, no Feb 10 00:04:11 stbuehler, what good is a landscape locked phone Feb 10 00:04:28 and then people are gonna bitch, you locked it ot the left but i want it on the right boo hoo Feb 10 00:06:41 kk Feb 10 00:07:29 i don't really need a terminal on my pre- anyway :) Feb 10 00:07:59 there is "occasions" where it could be useful Feb 10 00:08:13 but it wont be near the amount of time i use wterm on my TP Feb 10 00:08:43 wtf just happened to my twitter layout? Feb 10 00:13:15 * PuffTheMagic continues to press F5 waiting for a new commit from Brybry to showup Feb 10 00:13:35 I'm debating if I want to merge or rebase them in :D Feb 10 00:16:06 cherrypick Feb 10 00:16:23 but it wasn't just one commit :( Feb 10 00:16:44 u can cherry pick a range Feb 10 00:16:58 sounds like a rebase to me Feb 10 00:17:17 fuck this, I'm copy pasting Feb 10 00:20:52 0.4.0: Performance increases, less CPU usage, scroll-back buffer, automate non-root user setup, add exhibition mode support, limit just-type actions to non-root user, support for some phones, rotation/resize fixes, more escape code support, vkb click sounds, audible bell, paste
\ Feb 10 00:21:00 missing anything? Feb 10 00:22:54 * PuffTheMagic fires up GT5 while waiting Feb 10 00:23:30 new vkb layouts? Feb 10 00:25:20 god dammit Feb 10 00:25:28 EVERY time i turn on the ps3 there is a system update Feb 10 00:25:34 or an update for ht egame i want to play Feb 10 00:25:42 i can never use it when i want to Feb 10 00:25:47 always 30-300 min later Feb 10 00:27:11 vkb layouts are broken Feb 10 00:28:05 ya i just noticed that Feb 10 00:28:08 what happened Feb 10 00:28:27 there, pushed Feb 10 00:28:37 I DIDN'T DO IT Feb 10 00:28:46 I hope I didn't do it :( Feb 10 00:28:57 could be related to my rotation/resizing changes Feb 10 00:29:22 we get Feb 10 00:29:23 two plugins Feb 10 00:29:26 hahahaha Feb 10 00:29:27 that's awesome Feb 10 00:29:32 ? Feb 10 00:29:48 [20120210-01:29:40.594625] error: Uncaught TypeError: Cannot read property 'clientHeight' of null, src/enyo/vkb.js:165 Feb 10 00:29:49 like I tried to change layout and now I have two plugin objects one on top of each other Feb 10 00:29:51 [20120210-01:29:42.347397] warning: enyo.Component.addComponent(): Duplicate component name "terminal" violates unique-name-under-owner rule, replacing existing component in the hash and continuing, but this is an error condition and should be fixed., /usr/palm/frameworks/enyo/1.0/framework/build/enyo-build.js:72 Feb 10 00:29:53 each targetable Feb 10 00:30:00 and able to be typed into with a bt keyboard Feb 10 00:30:04 oooh Feb 10 00:30:13 lol Feb 10 00:31:31 I guess onPostRender gets called again when a new vkb is set up? Feb 10 00:32:35 I also wouldn't mind someone other than me testing out my input change before we do a new public release or something Feb 10 00:32:40 just to make sure I didn't miss anything Feb 10 00:32:48 stbuehler, how did u get those errors Feb 10 00:32:54 i dont get thenm :( Feb 10 00:33:16 palm-log Feb 10 00:33:20 just change keyboard layout in prefs Feb 10 00:33:44 I did qwerty (US)->qwertz (german) Feb 10 00:34:35 palm-log should get directed to eclipse Feb 10 00:34:55 maybe the log level got reset? I think it does every device reboot Feb 10 00:34:59 not sure Feb 10 00:35:08 I definitely get the errors as well though Feb 10 00:35:56 let me rebase on current head Feb 10 00:36:18 i fixed the term duplicate Feb 10 00:36:24 damn, why doesn't flex work -.- Feb 10 00:36:26 i will fix the clientHeight issue now Feb 10 00:40:50 vkb now starts in small mode Feb 10 00:41:06 doesn't care about the actual orientation Feb 10 00:41:41 ummm Feb 10 00:41:47 i fixed all the old bugs Feb 10 00:41:51 but i get mad duplicate keys Feb 10 00:41:58 s/keys/chars Feb 10 00:41:59 when i type Feb 10 00:42:44 hmmmmm Feb 10 00:43:15 well, perhaps time to start "return true" if you handled events :) Feb 10 00:43:15 shit its make a new terminal for some reason Feb 10 00:43:39 if createVKB gets called again it will created a second terminal too Feb 10 00:44:13 i tweaked the onPostrender callback so that it doesnt Feb 10 00:44:17 well Feb 10 00:44:20 now there are not 2 new ones Feb 10 00:44:28 but its not the old one Feb 10 00:45:03 I can't think of any possible way for duplicate keys unless you still have some old code in vkbKey mixed with new code in wterm_app Feb 10 00:45:15 createVKB shouldnt be getting called twice Feb 10 00:45:43 it doesn't even need to call createVKB twice Feb 10 00:45:45 go for printf debugging :) Feb 10 00:46:02 it just has to call render again on VKB Feb 10 00:46:11 I believe Feb 10 00:46:27 so i guess the flex: stuff is actually working Feb 10 00:47:16 pushed the german vkb layout Feb 10 00:47:47 if it doesn't work after you fixed the other vkb stuff, just revert it :) Feb 10 00:47:58 (but it worked for me before i rebased, so i think it should be fine) Feb 10 00:48:16 pushed the german vkb layout? Feb 10 00:48:20 the fix Feb 10 00:48:35 there were too much keys in one line as i didn't know how to make the shift key smaler Feb 10 00:49:26 now i made the left shift "flex:1", which is what they did on the real keaboards too (very small left shift key) Feb 10 00:50:38 stbuehler, the french layout prob needs that too Feb 10 00:52:13 k, last mission tonight :) Feb 10 00:55:03 i cant tell if a new term is being made or the shell is crashing Feb 10 00:55:41 yeah, I'm confused about that too Feb 10 00:56:31 terminal is definately crashing Feb 10 00:56:34 so much for a release Feb 10 00:58:08 I don't see a segfault or anything though Feb 10 00:58:40 well, I see one now Feb 10 00:58:53 but not the first two times Feb 10 01:01:48 hm, did € got lost in the font? Feb 10 01:01:52 it only shows '?' Feb 10 01:05:56 I dunno how to even backtrace this in gdb Feb 10 01:08:36 ok, azerty should be fixed too Feb 10 01:08:45 apart from € not working... Feb 10 01:22:55 * Brybry gets closer Feb 10 01:24:34 wterm_app.js:VKBLayoutChange() --> this.render() Feb 10 01:24:42 comment that out and no crash Feb 10 01:26:45 there was no crash, it just was re-rendering (i.e. recreating html nodes) the object :) Feb 10 01:26:50 no Feb 10 01:26:51 it was crashing Feb 10 01:27:04 no, it was a regular termination, as it was asked to do :) Feb 10 01:27:17 I got minidumps Feb 10 01:27:21 hm Feb 10 01:27:33 right, i remember it got sigsegv too Feb 10 01:27:39 and gdb pooped all over my face Feb 10 01:27:47 and wouldn't tell me anything :( Feb 10 01:27:56 yes, can't access memory Feb 10 01:27:59 but, yeah, it didn't ALWAYS segfault Feb 10 01:28:11 so I dunno, maybe sometimes it was closing normally too Feb 10 01:28:58 so last part: why is it starting vkb with wrong orientation style Feb 10 01:29:17 I don't have that problem =x Feb 10 01:29:58 try a different orientatio Feb 10 01:32:20 oh, there we go Feb 10 01:32:34 one of the horizontal orientations is messed up? Feb 10 01:32:41 I guess I should say landscape Feb 10 01:33:19 landscape with TP power cord to left Feb 10 01:33:44 I have no idea if that is left or right or what Feb 10 01:34:34 did i ever mention i hate it if people do if ... else without blocks? Feb 10 01:34:55 either put it one the same line, or make a new block and indent the inner part Feb 10 01:35:00 don't indent without a block -.- Feb 10 01:39:59 yay, typo Feb 10 01:40:11 found it Feb 10 01:40:13 reversed large/smalls? Feb 10 01:41:39 noope Feb 10 01:41:45 .orientation <-> ._orientation Feb 10 01:41:56 ahh Feb 10 01:41:59 that makes much more sense Feb 10 01:45:33 I wonder if that render is actually needed for anything anymore Feb 10 01:46:46 with my current diff it doesn't resize the vkb Feb 10 01:46:57 or it only resizes after the next change Feb 10 01:50:46 for me it's like the resize is delayed until the next change unless it's rendered that layout before Feb 10 01:50:56 ah got it Feb 10 01:51:49 pushed it Feb 10 01:52:00 have fun with it, don't break it^^ and gn8 Feb 10 01:54:17 yup, seems to work Feb 10 01:54:21 nice :) Feb 10 01:56:56 PuffTheMagic: I think we fixed everything, try head and tell me if you still have any input issues Feb 10 02:01:40 utf-8 still needs some work i guess Feb 10 02:01:46 another time Feb 10 02:20:50 Brybry, everything? Feb 10 02:34:29 well, the crashes and layouts and multiple terminal things? **** ENDING LOGGING AT Fri Feb 10 02:59:57 2012