Jump to content

CamBee

Level 2
  • Posts

    11
  • Joined

  • Last visited

About CamBee

CamBee's Achievements

7

Reputation

  1. I love the backlinks. I've been messing around with Obsidian backlinks and that is an exercise in fragility. Evernote really got this right! This opens up some other future possibilities as well. Very Nicely Done Evernote Team!! w/r to the backlinks being removed, I've not personally experienced that. I have, however, noticed that it often takes a number of seconds (~15/20 s) to sometimes add or remove a backlink. I'm very satisfied with the performance of this particular feature. the wait is minimal. I have a measly 6k+ notes, so I figure a few seconds isn't all that bad...
  2. Yes, I'm a long-term premium paid subscription user. Thank you both @Dave-in-Decatur & @gazumped
  3. Howdy Gazumped. I love Evernote. I'd never leave it due to such a small nit. I have reported this in great detail on the feedback site. Just checking to see if there are other relevant discussions to see if there is anything I'm missing. Is there a separate support site for Evernote? I've only seen the feedback section and this forum. Thanks!
  4. Actually, the use of DVORAK was dead until the computer. The average typing speed efficiency gained by DVORAK over QWERTY is about 80%. Would you like to double your typing speed? The audience of Dvorak users is growing, but not really the issue. The question at hand is that the treatment of keyboards is natively handled at the OS level unless the application bypasses that feature to try to manually (hard-coded) interpret the keyboard. If the OS input management system was used, DVORAK and QWERTY would not be different to the application as both are just binary mappings of the same keyboard to actual letter abstractions...using the OS would result in both being seen the same at the application level...hence no custom code would be required at all. The fact that DVORAK isn't mapping fully suggests the application bypasses the OS input management altogether. anyway, is a minor nit, but as a Tech Engineer, this is a bit of a head-scratcher.
  5. On computers, there is not really such a thing as a QWERTY keyboard. Your key mappings are all OS interpreted <default>. The underlying mapping of a binary value is interpreted by the OS. While there is a language symbol on the keyboard for your convenience, the OS does not see the value. That is why you can use control characters and symbols on your keyboard - because it is all 'abstracted' to binary values. So if the qwerty representation of an 'F' is under the left hand forefinger, but the DVORAK 'F' is where the QWERTY 'Y' would be, the OS interprets the physical binary into the resulting letter value. The application is a consumer of the OS interpretation...which is why this lack of support is odd. Because this issue suggests that the application bypasses the OS input management system... From an application development standpoint, you can use the input management system of the OS or you can choose to intercept that input yourself. It would Make little sense (imo) to intercept those values manually if you were intending to support more than 1 keyboard 'abstract' layout. ie, the US-QWERTY keyboard is only one of many, and that is great if you only intend to support 1 US-centric English keyboard only. But for a product and business that likely wants consumption in more than 1 country, it would make much better sense to leverage the OS mappings and only program to the exceptions of new language supported keyboards or non-conformant key mappings. With this approach the product will natively support multi-lingual multi-national keyboard mappings with minimal exceptions. otherwise every language or mapping supported would require a hard-coding for each one to be supported, which would just be silly. Of course, I could be missing something. Evernote is a quality product and I'm sure there is a reason for the decisions made on keyboard mappings. Just be aware that at an OS level, the QWERTY and DVORAK mappings are the same from an application point of view, unless the application is bypassing the OS input management system to interpret the keystrokes hard-coded assuming QWERTY is the intended keyboard. as I understand it.
  6. The OS provides keyboard options and internally remaps them. This is supported for different languages, different countries, etc. DVORAK is the ORIGINAL type-writer configuration of key orientation and substantially more efficient. The QWERTY key orientation is the MOST INEFFICIENT mapping designed expressly to slow down typers so that the mechanical keys wouldn't all get stuck when a fast typist was typing. With the advent of the electronic typewriters and computers, this limitation is no longer needed. Dvorak is a system provided keyboard mapping that is common in all OS's in common use today. However, the real issues is that the development of keyboard mappings should not be hard-coded, but rather should be an expression of the OS key mapping, obviously to support all languages, and keyboard mappings...so the lack of support of OS Keyboard mappings suggests hard-coding of the keystrokes. which is 'interesting'.
×
×
  • Create New...