Field focus is broken

[eee-c]

Sigh.

[influx6]

Hey brother why the sigh are you down on contributors? On Sep 7, 2013 3:20 AM, "Chris Strom" notifications@github.com wrote:

Sigh.

— Reply to this email directly or view it on GitHubhttps://github.com/eee-c/ice-code-editor/issues/58 .

[eee-c]

@influx6 Nah, I'm still more than happy to get some contributor help. I'm just a tad frustrated with some of the recent changes in Dart -- mostly involving keyboard input. This is another recent change in Dart that may be related to keyboard input.

I know the Dart developers will get this resolved quickly, but it's rough dealing with it currently. Hence the sigh :grin:

[influx6]

ah! i can understand your pain, isnt there anyway for you to abstract things away without much effect on your code and project,maybe its time to look at other alternative for keyboard input atleast till dart team fixes it, which ranges from some kind of javascript mix where (note am not sure how possible it is,but am sure it can be done), you delegate input processing to the javascript end of things

[influx6]

For example, we can use a form socket pattern or using the message/webworker api, the general idea is you delegate javascript to handle catching the keyboard inputs,now in the first step you can use some tag or script element hidden in your page,you simple watch the content of that tag which gets its content replaced by the keycode(the integer representing that key i guess) which you then take into dart and trigger the corresponding action.

The second method is creating two web sockets/web workers/message api, am not sure hence the or's ,but i think the message api should be valid,you simple send they keycode from the javascript end to the the message api at the dart end.

The third option is since dart can run javascript code(am not so sure on how this works since i haven't played with it) the general idea is the javascript gets the keycode when keyboard events happen and handles it off to dart like normal code.

But if you really think of it,when you look at portability and a method that works on all browsers, the first is the better option,a simple tag (custom or just a script tag).using innerHTML you replace it often with the key code or combination keycodes(maybe an array if its a combination) and you get that data and simply trigger the corresponding action on the dart end,these way you can keep your dart code current has the fixes comes in but you get your app working generally till everything can fully be in dart.

I know this might herk you since you might be a purist as i am,but in these case i think its a beautiful idea,the tag is the socket and dart and js are the reader and feeder. simple and should work but of course you will need to test.

SInce am nearly done with my final exams thanks to God above,i should be more free and capable of helping out,though my pull request might not be regularly since i will be offline most times until evening time,but still it's not a barrier,also been working on a flow based programming library for dart,since node has no-flow now, and i find fbp(flow based programming) very interesting concept,hope to implement ICE using flow style when the fpb library is at such a working state as a proof of concept also.

[eee-c]

The JavaScript suggestion was a pretty good one, but I am still limited to what Chrome supports when generating keyboard events. It turns out that it does not support very much: http://japhr.blogspot.com/2013/09/non-tainted-dart.html.

Hopefully the Dart maintainers will update KeyEvent very, very soon.

[influx6]

Wow that is really a pain, and am guessing there is no way of getting or patching up the keyevent yourself?

[eee-c]

Sure, but there is no way to get my version of Dart onto drone.io for contiuous integration. It would also make it harder to get collaborators since they'd have to build and compile my flavor of Dart.

[influx6]

Ok before anything, am still abit in the clouds when it comes to a few things, i understand the following:

1. there is a bug in the keyevent for dart which causes a problem
2. a solution can only be attained when its patched

But in my thoughts, isn't there any other method of accesing the raw key event of the dom without going through dart:html and if there is,even if not elegant,what makes it less worth it. Now being someone who at times is stuck in my own ways, i would have suggested why not go ahead and re-write your own keyevent but that brings us back to the being able to get to the raw dom api and what makes the javascript solution limited or unapplicable in your case. If i can wrapp my head around these things then maybe i can get a clearer picture of what is the problem. Because if field focus is affected by the bug,it can be only a matter of time till it spreads,but since the dart team has it on their rows i guess it isnt of high importance to worry much,but due to the flux of dart current development and push up, i think a sustainable alternative/backup solution should atleast be ready incase as things are,it breaks again.

[influx6]

And seeing am littering your issues with much comment,maybe you might prefer we move the discussion to something more realtime, I don't know how the time zones shifts for you but if you got time, am up late over so we can talk, its 8:42pm here, due to exam papers i can be up till 2:30am, since i gotta get up early to cook and rush off. I believe a better or rather a different eye to the matter my produce atleast a functioning solution as a backup.

But i could be wrong here :)

[influx6]

I havnt heard from you so guess you busy or down, well i await your response,will love to help as i can,take care man!

[eee-c]

@influx6 Sorry, I've continued to work through the problem and have a workable solution using js-interop eval'd code. That said, it sounds like Dart will support generating custom keyboard events imminently, so I have started the effort to support the planned API.

Let me know your thoughts, but I think the next steps are just waiting for the new API to land. Thanks for all the suggestions and encouragement so far :)

[influx6]

I believe it's a brilliant idea and provides a working solution at least though my inner purist cries out blasphemy :), because of Eval which is seen as unsafe but am sure the dart team have dealt well with the issues that come with it, my only suggestion is to just as you have done formalise the system a bit instead of doing specific key and character level binding you create something like a key event spie /leech either as pure js or using the js–interop method, you simply attach it to the dom element and as you've done, when an element within that particular element tree(itself and it's children), using the idea of live events but in these case your spie or leech gets triggered on all key or mouse event, extracts the event object information as above and sends it to ur js object while you have a pure dartobject where u can define custom callbacks for specific events or even type of events and trigger that, or them if it's a callback chain. This will allow a clean interface to it and all u are doing is attaching a single

[influx6]

Single callback through the js interop which extracts n feeds it to a stream which u listen to and trigger appropriate handler, it's cleaner and easier, also if u need to clean up u simple remove that callback and not sets of callbacks, also u get benefits of live events if new elements are added dynamic since you can target specific key event and best yet u get ur character based event setup since js handles that better itself. I hope I get it right!.

[influx6]

Will experiment with the idea myself! :)

----update: seems you already figured my above suggestions yourself in http://japhr.blogspot.com/2013/09/pre-supporting-api.html, so then i guess its all good!

[influx6]

Finally free from shackles of exams, Woot, so where are we and how can I help

[eee-c]

I'm just waiting for the KeyEvent CL to get the OK. Once that's been released, this (and a number of other things) should just start working again. Until then, things are in a holding pattern :-\

I'm messing around with drop events in the import milestone. In the meantime, there are other issues floating around -- feel free to pitch in if you like. #51 in particular has caused a few problems lately.

[influx6]

What if you change the store object into an atomic reactive object i.e instead of getting a hash maps when changed, we simple bind to individual values eg name, date when they change they propagate, This will reduces complexity but might require a rewrite

[influx6]

Also I don't know if you use any real time messaging system but would be nice to get to u realtime

[eee-c]

The implementation doesn't matter too much.

It needs to support listing projects (for the open menu), searching (for the filter), and opening by name. The Map made the most sense, but I'm not wed to it. That said, I'm not sure what a reactor really buys in this case. Still, I'm open to it.

I would prefer to keep the existing data structure in localStorage. These are kids that are using it. We can not risk losing any data.

Sorry, I avoid messaging systems -- too easy to break focus.

If we're talking about #51, we should probably keep discussion in that ticket.

[eee-c]

I believe that the fix for #75 addresses this bug.