Trackbacks

1. No Trackbacks

Comments

1. Haris says:
   
   #1 2009-04-17 18:55 (Reply)

   Great. Thank you for trying to develop our "Thaana".

2. ajaaibu says:
   
   #2 2009-04-18 06:34 (Reply)

   i wondered why u were not releasing public for that long. anywhr thankx dude

3. meekaaku says:
   
   #3 2009-04-21 06:28 (Reply)

   Nice work. Will be of great use.
   One problem is in the demo for setHandlerById, the text direction is not adjusted when thaana is selected. Others also when text direction is specified by class, if I turn off the direction remains rtl.
   
   I have tried modifying the setHandlerById to handle toggling direction. I think this method can be used for other functions as well. What do u think? I am pasting a patch (well two lines changed, against v4.2.1.
   
   
   --- jtk-4.2.1.js 2009-04-21 11:07:38.000000000 +0500
   +++ jtk-4.2.1.mkk.js 2009-04-21 11:14:58.000000000 +0500
   @@ -43,13 +43,13 @@
   case 'enable':
   // Enable input handling
   elem.onkeypress = this.handleKey;
   -
   + elem.dir = "rtl";
   break;
   
   case 'disable':
   // Disable input handling
   elem.onkeypress = null;
   -
   + elem.dir = "ltr";
   break;
   }
   },

4. jaa says:
   
   #3.1 2009-04-21 06:52 (Reply)

   Thanks
   
   Not switching the text direction in response to Thaana is indeed an oversight on my part and I'd need to incorporate that functionality in a future release. Thanks for the suggested patch!

5. jaa says:
   
   #3.2 2009-04-21 07:48 (Reply)

   Ah, no wonder your code changes looked so familiar. Turns out I had implemented direction handling, exactly as you have, early on when I started off the v4 series but had dropped it off by the final 4.0 release. The reason I chose to remove it, if I recall correctly, is that this approach does not respect the default direction for the field that the web developer may have already specified via CSS or HTML. When JTK is disabled for a field, it simply means that JTK is no longer handling the keyboard. Hence, forcing a field to "ltr" when input handling is turned off, is likely to interfere with the direction the developer had assigned for it before JTK came into play. I had intended to revisit the issue later and add the functionality in such a manner that the defaults are retained... Anyway, thanks again!

6. meekaaku says:
   
   #3.2.1 2009-04-21 09:54 (Reply)

   This works on FF. Not sure of IEx or other browsers.
   
   
   
   --- jtk-4.2.1.js 2009-04-21 11:07:38.000000000 +0500
   +++ jtk-4.2.1.mkk.js 2009-04-21 14:44:12.000000000 +0500
   @@ -43,13 +43,16 @@
   case 'enable':
   // Enable input handling
   elem.onkeypress = this.handleKey;
   -
   + elem.odir = elem.dir
   + elem.dir = "rtl";
   break;
   
   case 'disable':
   // Disable input handling
   elem.onkeypress = null;
   -
   + if (typeof elem.odir != 'undefined') {
   + elem.dir = elem.odir;
   + }
   break;
   }
   },

7. jaa says:
   
   #3.2.1.1 2009-04-23 08:27 (Reply)

   Awesome
   
   Again, surprisingly (or not) I too had experimented with using expandos for storing the default status but eventually decided against it because expandos are still considered a bit iffy. My biggest concern was that it has been said to cause memory leaks in some versions of IE. The approach I was/am planning to use is storing the data in the class property... but then again expandos are so much more convenient to use... I'll be investigating this a bit more when I have time and add the feature to the next release.
   
   Keep suggestions coming, thanks!

8. meekaaku says:
   
   #3.2.1.1.1 2009-04-24 13:39 (Reply)

   "..storing the data in the class property.."
   
   You mean simulate static variables? Would that not require an array to hold that direction info for all input fields?

9. jaa says:
   
   #3.2.1.1.1.1 2009-05-02 22:19 (Reply)

   Nope, not static variables...
   
   Your code added the custom attribute "odir" to the DOM to store the data which, it is argued, invalidates the document as the custom attribute is not part of the document namespace. Hence many consider it to be bad practice. The solution is to hijack an existing attribute, like class or rel to store the data. Most javascript libraries and frameworks use the class attribute to store extra data.
   
   Anyway, my preferred approach would be to add some code to manipulate the class attribute of the element to store the information... Your suggested code should definitely work fine in all modern browsers though.

10. Yusuf says:
    
    #4 2009-05-07 11:15 (Reply)

    thanks, this looks like a neat feature to incorporate on a dhivehi site I am working on, it would be in the backend thou... will give this a try and definitely report back...
    
    thanks again dude...

11. ibura says:
    
    #5 2009-08-15 10:10 (Reply)

    jaa, i came accross that we could either use thaana or latin with the keyboard right? if we want to use both latin and thaana then how? i have tried but it seems to mess up the content.

12. jaa says:
    
    #5.1 2009-08-21 03:45 (Reply)

    What do you mean by "use both latin and thaana"? Can you give a more detailed description of what you are attempting to do (or a demo)?

13. Hasan Yasir says:
    
    #6 2010-07-06 16:12 (Reply)

    Hello, I have seen almost all dhivehi websites using your thaanakeyboard to type thaana.
    
    I am also using your keyboard. But the problem with is I couldn't make your keyboard work with my HTML Editor (telerik asp.net) since it is using iFrame instead of html input.
    
    So my question is, is there anyway to solve this issue and apply your keyboard to iframe?

Add Comment