**** BEGIN LOGGING AT Wed Feb 08 02:59:57 2012 Feb 08 03:15:07 * rwhitby assumes the grinders are going to be webOS-powered, like the toaster Feb 08 03:20:50 rwhitby: heh coffee roaster webos powered. grinder? let's don't be silly! :P Feb 08 04:00:22 cryptk|offline: sounds interesting Feb 08 04:03:14 hm, never would have pegged cryptk for being married already Feb 08 04:03:58 rwhitby/destinal: probably ios, non-multitasking and all Feb 08 04:04:14 with just the one button Feb 08 04:04:19 dwc-: lol Feb 08 04:04:20 i think im gonna make an irssi script that creates dashboard notifications :) Feb 08 04:04:49 PuffTheMagic: I think there's already a growl thing, wonder if we should do a growl dashboard notifier Feb 08 04:05:20 PuffTheMagic: http://justindow.com/2010/03/26/irssi-screen-and-growl-oh-my/ Feb 08 04:05:30 http://andy.delcambre.com/2008/12/06/growl-notifications-with-irssi.html Feb 08 04:05:41 well there is no generic way to do dashboards in webos Feb 08 04:05:46 I'm not a big fan of growl Feb 08 04:05:55 at least the last versions I used Feb 08 04:06:03 so it would have to be a wterm launch param Feb 08 04:06:24 I wanted my alerts from adium, but mostly just to be an OSD, but even at full transparency, clicking on accidentally still interacted with them Feb 08 04:16:23 lalalala Feb 08 04:18:33 mmmmm Hilarie Burton on white colar Feb 08 11:15:50 ouch Feb 08 11:16:36 return enyo.json.parse(this.callPluginMethodDeferred(null, 'getDimensions')) Feb 08 11:16:41 this is pretty useless Feb 08 11:17:31 callPluginMethodDeferred doesn't return anything - the result is passed to the callback (null in this case) "async" (-> later) Feb 08 13:25:29 wterm.plugin[21867]: Failed to register playFeedbackCallback: Unable to dispatch service call Feb 08 13:28:18 yeah, we know about that Feb 08 13:28:42 I don't think anything has been decided on how we want to fix it :( Feb 08 13:28:44 why does it work sometimes? Feb 08 13:29:00 PDK can only register a luna service handle for the first card Feb 08 13:29:09 ouch Feb 08 13:30:43 which leads to the next question Feb 08 13:30:56 why is wterm still running after i closed all cards?... Feb 08 13:31:03 I think the ideas so far were to do it all in javascript, make calls to javascript to do it, or use liblunaservice ourselves Feb 08 13:31:06 oh, exhibition mode? Feb 08 13:31:08 maybe? Feb 08 13:31:30 hm, running is wrong Feb 08 13:31:31 exhibition mode apps never actually close Feb 08 13:31:32 they just idle Feb 08 13:31:32 Feb 08 13:32:07 if it's just one defunct and not new additional defuncts every time... Feb 08 13:32:21 so WebAppMgr didn't waitpid the zombies Feb 08 13:32:50 only 2, and not increasing right now Feb 08 13:33:09 hmm Feb 08 13:33:10 is there an easy way to restart WebAppMgr? Feb 08 13:33:19 no idea :( Feb 08 13:33:26 well, reboot it is :) Feb 08 13:33:39 I think you can kill those manually? Feb 08 13:33:56 i could have tried, yes Feb 08 13:34:06 no idea whether they get restarted by luna or whatever Feb 08 13:34:09 maybe not, I dunno Feb 08 13:34:19 not like zombies actually use system resources :P Feb 08 13:35:07 well, i had only one wterm card open and it couldn't register the callback Feb 08 13:35:17 oh Feb 08 13:35:22 well that definitely isn't good/shouldn't happen Feb 08 13:35:31 so i think the zombies counted as cards somehow Feb 08 13:36:01 WebAppMgr probably had cards allocated for them somehow, otherwise the wterm processes should have been collected Feb 08 13:36:28 oh fun Feb 08 13:36:41 13 "wTerm setup" icons Feb 08 13:36:54 huh Feb 08 13:36:57 when do we call PDL_Quit Feb 08 13:37:30 never Feb 08 13:38:46 that's maybe not good Feb 08 13:38:52 yeah Feb 08 13:44:14 I'm trying to think if maybe that was done on purpose/if it would mess up the multicard stuff Feb 08 13:44:21 I would think not but hmm Feb 08 13:46:30 step 1: pushed commit killing JSReply stuff :) Feb 08 13:49:22 oO. PDK wants PDL_Quit to get called before SDL_Quit. that violates some very basic nesting design - that you should cleanup in reverse order. Feb 08 13:53:37 well, i just added them Feb 08 14:17:46 and i don't get any keydown events on my pre- (webos 2.1) Feb 08 14:22:50 ah, no focus Feb 08 14:33:30 yeah, I know some workarounds to fix it (at least on the pre3) but I've been trying to see if I can get ApplicationEvents to work properly first (as there isn't really a reason that they shouldn't afaik) Feb 08 14:33:50 stbuehler, the setup icons are mysterious cruft from old installs Feb 08 14:33:52 or at least that's what I've been messing around with :D Feb 08 14:34:00 i can assure you im not making new ones Feb 08 14:35:58 PuffTheMagic: well, there just came back after a reboot Feb 08 14:36:03 s/there/they/ Feb 08 14:39:07 i dont think they get deleted Feb 08 14:39:10 i've seen them too Feb 08 14:39:12 sometimes Feb 08 14:41:05 pre3 runs webos 2.2, right? Feb 08 14:48:27 ya Feb 08 14:48:50 i still have focus issues on 2.1 Feb 08 14:49:03 yep Feb 08 14:49:14 i havent figured out a good way to auto focus Feb 08 14:49:30 what works on the pre3 and TP doesnt seem to work for pre2's and pre1's Feb 08 14:49:48 hm Feb 08 14:49:51 onKeydown Feb 08 14:50:03 isn't that a "native" event? Feb 08 14:50:51 onkeydown doesn't work either, well Feb 08 14:52:10 i think its bubble is getting canceled or something Feb 08 15:01:24 doesn't really make sense (at least on the pre3) because where the events get caught is enyo._popupLayer which is above wTermApp domwise Feb 08 15:05:03 this is for older devices Feb 08 15:07:08 yeah but the pre3 has focus issues too Feb 08 15:07:10 or at least it does for me Feb 08 15:07:35 i'll try the enyo.dispatch.features hook Feb 08 15:09:13 otoh.. what will the prefs dialog do if i catch all key events? Feb 08 15:09:31 bad things Feb 08 15:09:41 that's why we don't just use document.onkeydown Feb 08 15:14:34 you can hook all of the dispatcher functions and see where everything goes: enyo.dispatcher.oldmethod=enyo.dispatcher.method; enyo.dispatcher.method = function (arguments) { enyo.dispatcher.oldmethod(arguments); ) } Feb 08 15:14:56 or oldmethod.call(this, arguments) if it needs scope but I don't think most of them do Feb 08 15:17:07 it's actually kind of nice how they did the enyo event system as it's usually a little harder than that to hook into javascript event handlers Feb 08 15:35:21 hm Feb 08 15:35:22 very strange Feb 08 15:35:45 when the plugin looses focus i don't even see the keyevent in wterm_app::captureDomEvent Feb 08 15:38:41 try enyo.dispatcher.dispatchCapture and enyo.dispatcher.dispatch Feb 08 15:41:07 or just try enyo._popupLayer.keydownHandler = function(inSender, inEvent) { enyo.$.wTermApp.$.terminal.focus(); } and see if that fixes it for you Feb 08 15:43:24 dispatch: function(inEvent) { Feb 08 15:43:27 in plugin.js Feb 08 15:43:40 dispatch is a component method Feb 08 15:43:47 probably bad idea to overwrit eit Feb 08 15:45:44 for actual use? yes. for debugging? not really Feb 08 15:45:47 I do it all the time =x Feb 08 15:49:28 well, if you overwrite it, it should do something similar to the original Feb 08 15:49:37 for example same signature Feb 08 15:53:30 yes, you can do (literal code) enyo.dispatcher.olddispatch=enyo.dispatcher.dispatch; enyo.dispatcher.dispatch=function (a) { console.log("DISPATCHED "+a.type); enyo.dispatcher.olddispatch(a); } Feb 08 15:53:42 no, not that one Feb 08 15:53:52 that is the one that calls all others Feb 08 15:53:58 enyo.Component has a .dispatch method Feb 08 15:54:08 @protected -> undocumented Feb 08 16:06:43 [20120208-17:06:43.433044] error: RangeError: Maximum call stack size exceeded Feb 08 16:06:45 oO Feb 08 16:08:50 ^^^^ thats a fun error Feb 08 16:08:54 circular event chain Feb 08 16:09:10 :D Feb 08 16:09:45 this.dispatchFilter = enyo.bind(this, "dispatchFilter") Feb 08 16:09:54 it didn't like that Feb 08 16:20:58 hmm, what sends events to enyo.dispatcher.rootHandler.dispatchDomEvent Feb 08 16:22:48 if it can't find a defaultTarget Feb 08 16:23:12 and only enyo controls are valid targets Feb 08 16:23:33 hm no Feb 08 16:23:43 only registered "nodes" are valid targets Feb 08 16:26:40 i think i may have a working solution Feb 08 16:26:43 I think it's somewhere in that process that it's messing up Feb 08 16:26:54 (or at least on the pre3) Feb 08 16:27:03 but I'm still diggin Feb 08 16:30:05 on the pre- my dispatcher.feature is working well Feb 08 16:30:30 on the tp it breaks the enyo keyboard in the prefs Feb 08 16:31:41 ah Feb 08 16:32:37 can we make the enyo keyboard not resizing the plugin? Feb 08 16:37:34 ok, pushed it. no idea whether it works on pre3 though :) Feb 08 16:41:08 stbuehler: we can make it not reize the plugin, but then we need to be smart about scaling the prefs pullout Feb 08 16:42:47 kk Feb 08 16:42:55 can you test my commits on a pre3? Feb 08 16:45:03 I will in a little bit, I still want to see why this is happening =p Feb 08 16:46:48 hehe Feb 08 16:47:35 i guess it won't use rootHandler as long as the event targets anything in the body Feb 08 16:49:02 document.body.id is "" on TP, "popupLayer" on pre3 Feb 08 16:49:06 I think that's what bugs it out Feb 08 16:51:38 ROOT::DISPATCHDOMEVENTkeydown, src/enyo/wterm_app.js:185 Feb 08 16:51:38 APP EVENTS DISPATCH DOM EVENT:keydown, src/enyo/wterm_app.js:179 Feb 08 16:51:39 yaaaaaaaaay Feb 08 16:52:07 now the question is, does document.body.id = ""; break anything =x Feb 08 16:53:05 and, more importantly, why is enyo doing that on the pre3 and not the TP Feb 08 16:58:46 yeah basically if body.id maps to an enyo object instance I think findDispatchTarget returns that instead of pushing it to rootHandler (windowDeactivated and such have undefined targets and that's why they work) Feb 08 17:14:19 in the 3.0.2 release notes I see: PopupLayer: Prevent decoration of the body tag with class or id. Feb 08 17:19:32 what does the last commit fix? Feb 08 17:19:58 phone keyboard input focus issues Feb 08 17:20:04 but it breaks bt input on the touchpad Feb 08 17:20:38 I think Feb 08 17:20:39 maybe Feb 08 17:21:08 yup Feb 08 17:21:19 ah, because Feb 08 17:21:26 on the touchpad the event would properly go to application events Feb 08 17:21:31 and not popuplayer Feb 08 17:21:36 hm Feb 08 17:21:46 in that case you should catch onKeydown and onKeyup Feb 08 17:22:01 document.body.id = ""; fixes it =x Feb 08 17:22:08 with the old code Feb 08 17:22:25 just don't bring the .dispatch funtion on terminal back :) Feb 08 17:22:47 or, yeah, add onKeydown back Feb 08 17:23:37 are the enyo build.js on phones different from build.js elsewhere? Feb 08 17:24:53 err enyo-build* Feb 08 17:30:36 ah, they are =/ Feb 08 17:48:09 so the only input issues left are the remnants of the stuck key bug and maybe bt keyboards with phones Feb 08 18:45:11 i thought stuck key was fixed Feb 08 18:46:28 i am so confused by these commits Feb 08 18:46:39 stbuehler: i thought u said dont add back the terminal dispatch code Feb 08 18:46:45 but then Brybry's commit does just that Feb 08 18:48:22 he said terminal.dispatch Feb 08 18:48:23 I dunno Feb 08 18:48:26 it didn't break anything Feb 08 18:49:32 bluetooth keyboard input on phones is a little weird but I don't feel like looking into it right now (feels laggy and randomly key repeats when it shouldn't ._.) Feb 08 18:50:33 PuffTheMagic: stuck key is fixed for cases where the touchends are on keys but if they're on the keyrow divs they still happen Feb 08 18:54:18 like if you tap at the same time on R and in the space between F4 and F5 but the R finger releases first (it's hard to get the timing down, probably just easier to tap until it happens) Feb 08 18:54:50 Brybry: cant you add a listener on the area between keys Feb 08 18:55:09 Brybry: terminal.dispatch did what you added, its just in a different spot Feb 08 18:55:15 the same should happen if you manage to hit the 1px in between keys and be tapping at the same time (causing bundled events) and you release in the correct order Feb 08 18:55:31 PuffTheMagic, yeah, I know. I dunno what stbuehler had against that Feb 08 18:57:20 I think I looked into adding a listener for the area between keys but I didn't try too hard or I didn't like what I came up with or something Feb 08 18:57:56 I can look into it again Feb 08 18:59:00 I wonder if I can add some sort of handler to vkb itself and the touch events will bubble to that? Feb 08 19:06:20 thats what I was thinking too Feb 08 19:44:41 the patch was fine, and i only worried about the method name, not the content Feb 08 19:44:53 as it was conflicting with some internal name from enyo.Component Feb 08 19:46:43 i think i saw some code in the dispatcher stuff for handling mouse-move-out things Feb 08 19:46:50 could that be used to fix the stuck key issues? Feb 08 20:19:14 stbuehler, no it cant Feb 08 20:19:19 we cant use mouseout Feb 08 20:19:24 they conflict with touch events Feb 08 20:20:54 using onmouseout will break corded key bindings Feb 08 20:59:57 stbuehler, ping Feb 08 21:03:25 PuffTheMagic: pong Feb 08 21:03:48 and don't ask for highlight :P Feb 08 21:04:43 stbuehler, i was curious about the resize issue on the pre- Feb 08 21:05:39 shouldnt the textures get updated when the resize event changes the term dimensions and scales the video mode? Feb 08 21:05:49 there is no resize event Feb 08 21:06:25 the JS calls a plugin method on resize Feb 08 21:06:43 which sets term dimentions, sets a new video mode and triggers a VIDEOEXPOSED Feb 08 21:06:49 or something like that Feb 08 21:07:13 didn't see anything like that Feb 08 21:07:20 at least not in the plugin part Feb 08 21:09:12 there is an sdl event ofcourse, but it doesn't "happen" Feb 08 21:09:36 I don't think we catch onWindowRotated anymore Feb 08 21:10:02 ohhhhh hmmm Feb 08 21:10:13 i must have trimmed out too much Feb 08 21:10:20 we dont need to listen to onwindowrotated Feb 08 21:10:27 because when a window is rotated it is also resized Feb 08 21:10:54 i will look at the changelog and see what I removed Feb 08 21:10:55 i tried hooking into some js method of plugin, but it didn't work Feb 08 21:11:02 resizeHandler or something like that Feb 08 21:11:05 so, back to dota :) Feb 08 21:11:24 i will fix it Feb 08 21:11:30 stbuehler, dota? Feb 08 21:16:23 warcraft3 custom map Feb 08 21:20:11 stbuehler, this.$.terminal.resize(width, height) Feb 08 21:22:01 stbuehler, that "should" trigger a VIDEOEXPOSED event Feb 08 21:26:55 hm Feb 08 21:27:18 well Feb 08 21:27:22 the plugin object perhaps should Feb 08 21:27:28 but it doesn't on pre-/webos 2.1 Feb 08 21:30:52 does the JS-side resize actually fire but just the SDL-side event doesn't happen? Feb 08 21:33:53 i didn't check that part :) Feb 08 21:40:13 throw a logging statement in plugin.js:resize() then one in SDLCore::handleEvent() for the SDL_VIDEORESIZE, hide/show vkb (this fires a manual plugin:resize()), then rotate Feb 08 21:40:38 I think that'll cover all the bases for where it's messing up Feb 08 21:40:43 stbuehler, where did the enums go? Feb 08 21:40:53 the MOD enums? Feb 08 21:40:55 sdlk Feb 08 21:41:01 sdlk.js I think Feb 08 21:41:04 no Feb 08 21:41:09 js dont have enums Feb 08 21:41:12 C++ enums Feb 08 21:41:14 it does now Feb 08 21:41:17 ^^ Feb 08 21:41:20 ? Feb 08 21:41:47 which enums? Feb 08 21:42:00 there are many enums Feb 08 21:42:10 so perhaps you can tell me which enums you are looking for :) Feb 08 21:42:12 the ones where all the _t's were Feb 08 21:43:03 you named all your stuff _t Feb 08 21:43:09 so not helping :) Feb 08 21:43:49 src/models/sdlk.js has all of the key event SDLK_ enums, screenbuffer.hpp has the graphicsmode/color enums Feb 08 21:43:54 I can't really think of any others that have moved Feb 08 21:43:57 im not talking about key shit Feb 08 21:44:17 seqparser.hpp for the tokens Feb 08 21:44:17 i guess they were all in the vtterminal code Feb 08 21:44:19 and not in sdl Feb 08 21:49:26 stbuehler, / listenthread notify Feb 08 21:49:32 ^^ that is for keyrepeat? Feb 08 22:08:24 Brybry, think we need to ignore the SDL_VIDEORESIZE event Feb 08 22:08:28 and push our own event Feb 08 22:13:47 that could work, I was thinking of if we just fired our own SDL_VIDEORESIZE from plugin.js:resize() if version <= 2.1 but making our own event might be cleaner Feb 08 22:13:59 that's assuming that plugin.js:resize() is getting called Feb 08 22:26:59 listenthread is for timers (also supports fd polling) Feb 08 22:28:21 if sdl waitevent had a timeout the thread wouldn't be needed, at least not for timers Feb 08 22:28:52 why ignoring SDL_VIDEORESIZE? just make sure it fires Feb 08 22:29:08 stbuehler, it doesnt fire Feb 08 22:29:13 so we need to send out own even Feb 08 22:29:17 ... Feb 08 22:29:50 ok Feb 08 22:29:59 you make sure javascript sends a call to the plugin Feb 08 22:30:05 i'll handle it :) Feb 08 22:30:16 i got it already **** ENDING LOGGING AT Thu Feb 09 00:04:03 2012 **** BEGIN LOGGING AT Thu Feb 09 00:12:16 2012 **** ENDING LOGGING AT Thu Feb 09 00:58:29 2012 **** BEGIN LOGGING AT Thu Feb 09 01:10:17 2012 Feb 09 02:22:33 stbuehler, Brybry im disabling rotation on 2.1 Feb 09 02:22:37 this shit is fucked up **** ENDING LOGGING AT Thu Feb 09 02:59:57 2012