Edit OSX Keyboard Buffer - macos

I’ve got a MacBook Pro with the double-typing problem (and no, not a cleanliness problem) , and since apple wants north of $1000 to replace the keyboard, I’m hoping for a software solution.
Specifically, there are a handful of keys on my keyboard which frequently insert two characters per click, and I’m willing to bet that most of the time they are inserted into the keyboard buffer within a couple milliseconds -- which is faster than I could possibly type. Hence, I’m wondering if it’s possible to identify when a key has been “pressed” twice in the span of, say, 5ms, and delete the second keystroke.
I'm happy to do the work to code up a solution, but I'm not sure if it's even possible, so I'm looking for some guidance as to what software is even capable of editing the keyboard bbuffer. Automator? Apple Script? Something else?

Related

SDL2 program doesn't show IME candidate window

I’ve been having some inquiries from CJK players of my SDL2-based game on Windows, asking about IME text entry; the candidate list window simply doesn't appear for them, making it impossible (or very difficult) to type certain glyph compositions. Right now I’m using the current latest SDL2, version 2.0.12.
As far as I can tell, I’m doing everything in approximately the right way; calling SDL_StartTextInput() when keyboard focus is moved to an (in-game-rendered) editable text field, and SDL_StopTextInput() when the keyboard focus leaves it, as well as setting SDL_SetTextInputRect() to tell the OS where the text field is. SDL_TEXTINPUT and SDL_TEXTEDITING events seem to come through the event loop as they're documented to do; everything seems to be working, except that the candidate list window doesn't open.
And it all works exactly correctly in Linux and Mac builds, with IME candidate list windows popping up at the right times and right places and functioning correctly to allow entry of composed CJK unicode glyphs, on those OSes. It's only on Windows where the candidate list window just never opens, which is a big problem for a bunch of my players. Does anybody know how one is intended to handle IME compositions under SDL2 on Windows? (I'm doing all of this testing with Windows 10's default IMEs for Japanese and Simplified Chinese)
Can anybody fill me in on how the system is intended to be used? The tutorial page on input methods is really thin on details, and I can’t find a real demo program which shows how IME is actually intended to be handled in SDL2, or I’d just copy what they were doing.
May or may not be relevant, but my game is an OpenGL 3.3 game, using SDL for window management, input, and cross-platform multithreading support; we’re not using SDL’s built-in renderer at all.
EDIT:
I’ve put a minimal example program over here on GitHub, demonstrating what I’m seeing. It’s just fifty lines of C code, so if I’m doing something catastrophically silly, it should hopefully be pretty easy to spot!

Is it possible to programmatically turn on the Macbook Pro's keyboard backlight for individual keys?

Although I have a feeling that this isn't technically possible, it's worth asking anyways. Is it possible to turn on the Macbook Pro's keyboard backlights for individual keys? I am working on a piece of grid-based software which allows the user to navigate around by pressing any key on the keyboard to position the cursor at that point in the grid. It would be very cool if I could somehow just turn on the backlight for certain keys to give the user an easy way to see the current position of the cursor.
Is it even possible for an application to control the keyboard backlighting at all, let alone for individual keys?
Yes, on programs controlling the backlight.
iTunes visualizer that pusles keyboard backlighting to music:
http://www.youtube.com/watch?v=LUXLkwlF9e8
How to manually adjust (via plugin):
http://osxdaily.com/2006/11/30/how-to-manually-adjust-the-macbook-pro-keyboard-backlight/
Not sure on programs controlling individual keys, but as that would require additional hardware to be installed on Mac's part, i doubt it.
Well after trawling the webs, it looks like the answer to that is no. But I'd like to point out that each key does have its own key- a tiny little LED (same kind they use under phone keypad buttons). Also, I've seen some people saying that flashing these lights on and off repeatedly is bad for them. Bullshit- all digital electronics control light output from LED's by flashing on and off many many times a second. Read up on PWM on wikipedia or something..
Anyways just had to get that out there :)
Thanks,
Nic

What is the rationale behind Most-Recent-Order for tab switching?

I can't understand the reasoning behind Most-Recent-Order (how Windows sorts windows when switching via Alt+Tab) when used for tab/window/document/task switching. The way Firefox does tab switching (tabs stay in a consistent order, Ctrl+Tab/Ctrl+Shift+Tab for moving to the next/previous tab) seems much more natural than switching in chronological order.
When there are more than ~5 tabs or windows, I quickly forget the chronological order in which they were opened. So the sequence of switching between them becomes difficult to predict. Even if I remember which tab was active before the current one, and which one was active prior to that, it just takes a lot of key strokes to switch to these. More than if I could simply use direct order as in Firefox or Chrome.
Is there any rational reason to use MRO in an application apart from backward compatibility (for users accustomed to the old hotkeys and usage patterns)?
Why is it still used in Windows for Alt+Tab switching between applications?
It's used because often you're switching between two applications so it's a simple Alt+Tab to switch back and forth. If it didn't use a most recently used order it could be mulitple keypresses to switch back and forth between the two apps I'm interested in at the moment.
Similarly, in an IDE, I could be switching back and forth between two files and don't want to hit Ctrl+Tab lots of times to keep making the same switch.
I appreciate it in Windows Alt-Tab switching, but hate it for situations where tabs are visually present at the top of the screen. When I can see the tabs, I want to switch between them in the order I can see them, since I can probably at a glance (and without any conscious effort) count the number of times I need to press tab; and generally I'm working with few enough tabs (I'm an avid hater of clutter) that this works for me.
In Windows, when the alt-tab dialog (if dialog is the appropriate term) doesn't persist, I want to use MRO for switching.
People usually work well with a few items at a time, and the attention span allows us to better concentrate onto a couple of recent pieces of information rather than onto lengthy lists. Think of it in terms of caching this recent information: if you've used something in the last couple of seconds, and switched away from it for a moment, it's likely that it will be the first thing that you'll want to use again when you switch.

User interface paradigms that need changing?

Often times convention is one of the most important design consideration for user interface. Usually the advice goes to do it like Microsoft does.
This is for three reasons:
If it ain't broke, don't fix it.
If your users expect to click on a floppy disk icon to save, don't change the icon (even though some of them may have never seen an actual floppy disk).
Users don't want to re-learn the interface (and hot keys, etc.) with each different application they use.
At the same time Emmerson said "*A foolish consistency is the hobgoblin of little minds.*" So when does maintaining a consistent user interface cross the line from a good idea to stagnated innovation?
Microsoft shook up the good old WIMP GUI with the introduction of the tool bar, and then again with the Ribbon control (which is the natural evolution of the tool bar, like it or not.) Now we are seeing ribbons everywhere.
So my question is, what are some user interface paradigms that are accepted and consistent across multiple applications, but have stayed past their prime and are starting to reek? Are there some important changes that would benefit from a grass roots push by developers to innovate and improve the user interface experience for our users?
One thought that came to mind for me is the modal pop-up dialog. You know the ones that say: "Are you sure you want to . . .. - [Yes] [No] [Cancel] [Maybe]" and its evil twin "Successfully completed what you wanted to do! [OK]." We are seeing a movement away from these with the "info panel" in browsers. I think they need to be adopted in windows application development as well.
If possible please list a solution for each stale UI item.
And please don't list clippy. We all know he was a bad idea.
NOTE: This is specifically Windows client user interface paradigms, but I am certainly open to drawing inspiration from the web, the Mac, etc.
You mentioned popup modal dialogs , and I'd argue that non-modal ones are just as bad. Any dialog box remove focus from the program, they could end up behind the program and make it hard to find it, they might not even appear on the same virtual screen.
I'd like to see an end to all dialog boxes. If you need to stop someone from using the UI because of some non-normal circumstance, then remove the relevant parts of the UI from the window, and replace it with what the dialog would contain. Bring back the UI once the problem has been handled.
Clicking things on touch interfaces
It's incredibly difficult to click on things on a touch interface, because you don't know when you have pressed the screen hard enough. And if you add an animation to the button you are clicking, you most likely wont see it, because your finger is in the way. Adding other reactions, like vibrating the phone or painting waves on the screen might work, but there is usually a delay which is too large, much larger than the tactile sense of a button being pressed. So until they invent a screen with buttons that can be pressed, all touch devices should move towards dragging user interfaces (DUIs) instead.
Counter intuitively it is easier to press an object on the screen, drag it, and then release it than it is to just press and release it. It's probably because you can see the object moving when you start dragging, and you can adjust the pressure while dragging it. Dragging also has a lot more options, because you now have a direction, not just a point that you clicked. You can do different things if the user drags the object in different directions. Speed might also be used, as well as the point where the user releases the object. The release point is the real strength of DUIs, because it is very easy to release something, even with pixel precession.
Some designs have started to use DUIs, like (here we go) the iPhone, palm pre and android phones. But only part of their design is DUI, the rest is clicking. One area they all have in common is the keyboard. Instead of clicking on a key the user presses any key, then drags their finger towards the key they really wanted to click. Unlocking these phones also uses dragging.
Other easily implemented DUI features would be things like mouse gestures, where dragging in different directions, or drawing different shapes does different things. There are also alternate keyboards being researched which puts a bigger emphasis on dragging. All buttons can be changed into switches, so have to drag them down a bit to click them. With a well designed graphics, this should be intuitive to the user as well.
The Apple Human Interface Guidelines are a good read on this topic. They discuss this from a very broad point of view and the guidelines apply to any platform, not only Mac.
The file system. I want to save a file.. >OOOPs I need to think of a file name first. Well.... how about ... blah.doc.
6 months later...
Where the %#*(%& * did I save that %()#*()*ing file?
The solution is build a versioning system into the application, or better, the OS. Make files findable by their content, with a search engine, instead of forcing the user to come up with a memorable name, when all they want is for their file to not get lost.
Eliminate the save step. Type something in to the application, and it's just there, and there's no risk of losing it by some misstep, like forgetting to save. If you want an older version, you can just pick a date and see what the document looked like back then.
To build on the search engine idea: It's a pain having to navigate some arbitrary tree structure to find your stuff. Searching is much easier. However, you might still want to have something like a "folder" to group multiple files together. Well, you can build a richer metadata system, and have a "category" or "project" field, and setup the search engine to show items by project, or by category. Or group by those, or whatever new UI discovery we make next.
This question is a bit too open-ended, IMHO.
However, my main approach when designing anything is:
Fits in to wherever it is. If it's a windows app, I copy MS as much as a possible
It's simple.
It provides options
Buttons have a nice description of what the result of clicking will be, as opposed to 'yes or 'no'
Harder to answer the rest of your post without spending hours typing out an arguably useless (and repeated) set of guidelines.
In my mind, the one thing that really stands out is that USERS need more and easier control over the application's user interface appearance and organization.
So many interfaces can not be modified by the user so that the most used/favorite functions can be grouped together. This ability would make your favorite software even easier for you to get things done.
Error messages need a "Just do it!" button.
Seriously, I really don't care about your stupid error message, just DO WHAT I TOLD YOU TO DO!!!
I think the entire Document model of the web needs to change. It's not a user interface, but it leads to many, many bad user interfaces.
The document model was a good idea to connect a bunch of documents, but now the web is also a collection of applications. Today, I think the Page/document model corrupts our thinking. We end up lumping things together that aren't related, modularizing our code wrong, and in the end confusing users with our monolithic control board type websites.
Find dialogs that sit over the widget in which you are doing the search are terrible. Loads of apps do that. The find bar in Firefox works much better.
Many applications have multiple panes within the UI - eg in Outlook there's the preview pane and the inbox pane (amongst others). In these applications typically cursor key presses apply to the currently focussed pane. But there's very poor hinting to show the user which pane has focus and there are seldom keyboard shortcuts to move the focus between panes.
The focussed pane should be highlighted somehow.
Something like alt+cursor keys should move the focus around.
Ctrl-Tab and Ctrl-Shift-Tab cycle left and right through tabs instead of MRU behavior, even though in most cases the same behavior is duplicated with Ctrl-PageUp and Ctrl-PageDown.
There are a lot but here's an idea for a couple of them:
Remove some clicks like in "add another" or "search item" and the like.
This is well done with interfaces like ajax which have autocompletes ( and auto search ) but is slowly being adopted for platform UI's ( and in some cases they were originated in platform UI's. )
This is how StackOverflow does it for some scenarios.
But of course, we all know that already don't we? No need for "Seach tag" or "Add another tag" buttons, they just happen
Dialogs as you described.
Guys at Humanized proposed Transparent messages which actually are used in their product Enso and some other places.
Mac uses them for notifications ( like in Growl ) use them very well, or Ubuntu new notification system.
alt text http://blogs.sun.com/plamere/resource/NowPlayingGrowl.png
Firefox replaces the traditional "Search" dialog box with a search bar at the bottom.
Although not everyone likes the placement for next/previous as in this screenshot
And even SO ( again ) :) replace the notification with the yellow bar.
Finally:
File managers
I really like ( sometimes ) the simplicity of regular file managers, but some times I would like to work faster/better with them.
If you compare IE 4 with IE 8 you can tell the advance ( even better compare IE 4 with Google Chrome )
But if you compare Windows 95 Explorer with Win XP they are almost the same!! ( Win Vista/7 is a step forward )
But I wonder: Why haven't file managers improved as much as webbrowsers?
That's one reason I like stuff like QuickSilver but it is just a step. Much work is needed to create something like a "Perfect program launcher" or (FileManager/DesktopSearcher etc as you wish )
QuickSilver featuring "move to" action

Save icon: Still a floppy disk? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm working on a project where the user is able to save their work (most likely to the HDD but also possibly any other media, including floppy disks). Sure, the popular File > Save option is there but what about a toolbar button?
By far the most popular icon is the floppy disk. However, the chances the user will write to the floppy are pretty slim. Still, I think the floppy is more representational than literal.
In the end, I'll probably stick with the floppy disk icon to keep the convention most users are familiar with but... anybody have any ideas on how to update this old icon?
The floppy disk icon has become the standard for saving files. It's a highly recognizable icon and there's no reason to change that. Consistency between applications is a wonderful thing.
I suspect that over time the icon will grow more stylized and less like an actual floppy disk once people start forgetting what they look like (or never knew). The icon nowadays represents the concept of saving more than it represents floppy disks anyway.
As others have said, keep the floppy icon and don't worry. Where I live, this is the warning sign for train crossing:
There haven't been any steam locomotives for 50 years or so, but everyone still knows that this is the symbol for trains. And in the same way, 50 years from now, when your files are stored on Google servers in orbit, everyone will know that the floppy is the symbol for saving your data.
Consider the fact that you're using the term "floppy" when in fact the 3.5" disks were not floppy at all. It was just a term that carried over from 5.25" disks because everyone got used to it. The "disk button is save" concept is also what everyone is used to. Stick with it.
Chapter 17: "Rethinking Files and Save" of About Face covers this. Alan Cooper is well-known as a usability expert and his writings are influential. His argument is essentially that when we force the user to think about the implementation, we get ourselves into trouble. Here's a brief excerpt:
In the world of digital technology,
the place where implementation-model
thinking most strikingly rears its
ugly head is the management of files
and the concept of "save." If you have
ever tried to teach your mother how to
use a computer, you will know that
difficult doesn't really do the
problem justice. Things start out all
right: You start up the word processor
and type a couple sentences. She's
with you all the way -- it's like
writing on paper. But when you click
the Close button, up pops a dialog box
asking "Do you want to save changes?"
You and Mom hit a wall together. She
looks at you and asks, "What does this
mean? Is everything okay?"
This problem is caused by software
that forces people to think like
computers by unnecessarily making them
confront the internal mechanisms of
data storage. This isn't just a
problem for your mother; even
sophisticated computer users can
easily become confused or make
mistakes. People spend thousands of
dollars on hard- ware and software
just to confront impertinent questions
like "Do you really want me to save
this document that you've been working
on all afternoon?" and must remember
to use to the Save As... command when
what they really want to do is work on
a copy of the document.
It's worth thinking about ways to simplify or eliminate the "save" metaphor.
Here on Stack Overflow we can "Post an Answer" or "Add Comment" or "Ask your Question" for example. Each time we really are "saving" to the database, but the metaphor is slightly different each time. Posting, adding, asking. I think of software like iTunes which I believe does not have the concept of "saving to disk" for the music. You simply add music to it and it's saved. Depending on the type of tasks your software carries out, there may be different metaphors which are more apt than save.
I should mention that I've not really answered your question, I myself have used the floppy icon, or a big button that just says "Save" on it in my web applications. For the time being we're stuck with it for many cases, but it gets more and more ridiculous as floppy drives die out. But then, we also say we "dial" phones, when dial-interface phones have not been in popular use for decades.
Use an icon containing two characters:
:w
Look at your brand new cell phone's voicemail icon. There's a good chance it's still the 'tape rollers' icon from magnetic tape based home answering machines.
EDIT:
Okay, not all phones use the icon, but how about the word 'rewind'? I'm sure a few people out there have devices which allow you to 'rewind' a digitial audio or video media file.
If you think about it, mail has no "modern" representation either and is still represented by a paper letter.
(image from "It's Time to Change that Metaphor")
As mentioned in the blog entry "The end of an icon"
It’s dangerous to base a visual analogy on a moving target. Technology will change. What’s clear and obvious today won’t be in 10 years; so what’s nebulous today will be totally obscure in 10 years. The problem with the floppy icon (beyond the iffy analogy) is the generation gap.
Still, as long as the underlying action is clear, that icon will survive.
(image found in many places, including in this blog post)
Why do we even need a "save" function? Anything I write should be automatically saved, and in fact Microsoft Word does that already--if it crashes and haven't saved, your data is still recoverable. Google saves drafts automatically. Why do we still use the "save" paradigm?
Tango icon set have an arrow pointing down to a harddrive:
How about a reel tape drive like they had in the old Sci-Fi movies:
+-----+
|() ()|
| \ / |
| W |
+-----+
This icon would be timeless!
So long as most applications continue to use the floppy icon, most users will be familiar with it and your application will benefit from a familiar interface. In economics, this is known as a network externality.
When there's a problem with some code we say there's a 'bug' in it, even though the last time that actually happened was over 60 years ago!
You know, in 50 years, icons won't be needed. If you want to save your work, blink twice, or stand on your head, or just say "Save" in the language of your choice, and voila - it's saved... no need for a visual anymore :)
I vote using the standard 3.5" icon. When the day comes that it's confusing to users, developers will get plenty of complaints from users saying it's not "user-friendly" enough. As for now, we've been conditioned to look for that disk icon. I used an app once that used a CD icon instead, and it took me a few days to realize that it was used to save. It's all about design consistency and fulfillment of expectations.
If you deviate from the common icons for operations like save, your users are going to say your programs is hard to use. Even if you simplify everything so that you think it's perfectly intuitive and much better than what everyone else is doing, they'll say it's hard to use, just because it's not what they're used to and not what they expect. Remember, to your users, whatever Microsoft and the other big guys do is "correct," so if you're doing something different, you are, by default, wrong.
Besides, even if your user takes 5 or 10 seconds to figure out where the save button is, that's 5 to 10 seconds of easily avoidable frustration you could have saved them, and it's just one more barrier preventing them from being able to use your app. Obviously, they're not using your app to revel in the joy of clicking a chronologically relevant save icon. They simply want to avoid losing their work and get on with more important things in life.
Stick with the 3.5" disk; it's a financially sound, if creatively poor, choice.
Not really. As long as it looks likes the more modern "stiffy" rather than floppy.
Memory stick don't really have the same nostalgia. However as more and more modern systems don't include a physical stiffy drive, users of the future may not know what a "stiffy" stand for. As a teenager what a vinyl was and they might think your having a senior moment.
Picture of a Safe might imply that you are encrypting with some internal password and storing it so safe it won't be retrievable.
Picture of Server again givies the impression that its to be copied elsewhere.
Stick with the stiffy for the next 5 years
Cheers
I think this approach is on to something:
IMO, icons are useful because they're constant symbols we can associate with different actions. In that sense, the floppy is very appropriate simply because it is nearly universal. Never once in my life have I seen an interface with unfamiliar icons (no text at all) and been able to figure out what it does (I'm looking at you, Mac OS). I think even if you come up with an image that is more true to what is actually going on, such as a picture of a hard drive, you'll cause far more confusion than if you left it alone. Even if people such as myself can identify the icon as a hard drive, that doesn't tell us what you're going to do, it just means a hard drive is somehow involved...
Unfortunately this floppy disk icon has become the universal symbol for saving a document. It is even used in Microsoft Word 2007, virtually untouched. Change it in any way, an it is likely that you will make it unrecognizable to your users as a save symbol.
It's still in Windows' standard toolbar image list.
Nobody has seen a hard-drive, but that doesn't stop the icon from being one. To most users: a hard drive is that box on the floor.
It's the stylized symbol that is important. The picture can be a red cricket - as long as everyone associates that red cricket with saving.
Microsoft did a pretty good job of throwing out standard menus and icons in its 2007 office suite. Just about every average/beginner user just hates it for that...
To be honest, the floppy icon never made much sense to me. It means "disk activity", and it could be Save but Open as well.
The problem is that there is a new generation of users that have never seen a floppy disk (e.g. my 11 years of nephew) and he had to learn that that weird squared thing was Save.
I like the icon of a folder with an arrow pointing towards it. Maybe an arrow pointing to a cylinder (a la DB)?
I don't really like the other ideas a lot, so keeping the floppy icon is the default solution. Also, I hate the non-MS big low quality floppy icons some apps use.
Other solution could be a small version of the app icon with a hard drive and the arrow from the first to the second, but that won't look fine on a 16x16 icon.
What's clear is that icon design is science and art. I have a lot of respect for good icon designers.
Have you ever used HLSS? They use an image of a SD card as a save icon, yet most of the time, I can't pick it out on the toolbar and have to go to File -> Save to save.
So, they present an alternative modern equivalent, yet it doesn't work as well as the ol' 3.5" floppy icon.
Users using your application will find it more usable if you use a floppy disk icon. For consistency, if it makes you feel better. It's ubiquitous.
I think the nostalgia is neat - everybody knows what it means. I just took a quick look and Outlook still uses an old-school honkin-huge handset icon to make a call.
Great question. Of the 4 computers I actively use, only 1 even has a 3.5" drive. It is an antiquated technology that I, for one, wouldn't mind seeing replaced even in icon form.
Possible replacements:
a vault icon. Easily recognizable and symbolic of saving.
a compact disc symbol. More modern but still capable of being outdated soon.
???
I'm surprised at most of the responses here. The general consensus seems to be "keep using the floppy since that's what has always been done." Since when has the programmer mentality been to conform to everyone else's ideals? Doing something just because "That's the way it's always been" is no excuse, especially for coders.
You could use upload and download (red up and green down arrows) icons for saving and loading. Besides, in a short time network will be most place to save files.
Even though many people won't recognize what the icon actually is, they will quickly learn what it means, so I would keep it for consistency with other apps.
In the future, I think the question will become moot as more and more apps will avoid "Save" actions and save each user action automatically. Instead of discarding changes by not saving, people will use "undo" as the dominant paradigm for discarding changes.
It's funny that I found this discussion because I was looking for a standard 'save' icon I could download to replace the 'new and improved' icon that UtlraEdit started using and which was too difficult to pick out on the toolbar. Yes, it is outdated, but everybody recognizes the 3.5" floppy disk image as representing 'save'! Yes, programmers should not be doing things because 'that's the way it's always been done' but icons are language and not methodology. Don't invent a new word just because it would be cool unless your aim is to hide what you are saying from the previous generations.
I think in general the floppy disc icon has become the accepted save icon, even if it doesn't have much bearing any more with flash memory and DVD's being pretty ubiquitous. Frankly, if a program had an icon for saving that was something like a memory stick or HDD, most users wouldn't be able to pick it out as the save icon.
As pointed out by others the floppy disk icon is embeded in peoples understanding of computer user interfaces as the standard visual representation of the act of saving something.
The use of the floppy disk icon is a reflection of the technology that was prevailent at the time and so represented something the average user could quickkly associate with the act of saving a file.
The fact that the action of saving is still visually represented by the floppy disk in spite of it's rapid demise in recent times demonstrates the strength of association between the icon and the act of saving a file. If one were to attempt tp change the icon one would need to choose an image which is
Easily associatable with the act of saving as the floppy disk already is
Likely to remain in use, or at least in recognition, long enough for a sufficiently high number of people to recognise it
While I do acknowlege that the floppy disk has certainly outlived it's usefulness as the primary storage media of choice, I don't see it's role as the save icon ending in the near future.
If the icon were to change I believe major OS and hardware vendors would need to support such a change, which I don't believe is likely as doing so would potentially alienate a large number of existing users

Resources