= 27d567bc2d48d9f40e9ccc20ea370b15)
CAE_Jones comments on Group Rationality Diary, May 16-31 - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (15)
I tried outlining the different parts of my accessible image viewer/editor, and realized that the Ugh Fields keeping me from working on it are specifically around the UI and user-controlled settings; I can toss out code for the actual viewing part in five minutes, but working it into a larger program collapses from the weight of the rest of it. The trouble is that it's not testable without a minimum of lots of user controls.
Other than breaking it up into as many different chunks as possible (bound to be messy, but possibly more likely to get done), I haven't come up with a means of exploiting this to complete the program.
What are you using to program the UI?
I've had my UI-design experiences vary from easy (webapps via servlets and jsp, Hypercard), to easy so long as I was trying to do exactly what it was made for (Java with Swing), to so obnoxious that I gave up (C with GTK UI elements).
I've tried it two different ways, but the one that seems best is Java via Swing (the other approach involved me needing to build an imageIO library from scratch, which would just be silly). Making Swing accessible, though, is rarely worth attempting, so I was hoping to make liberal use of shortcut keys, spoken feedback and component titles.
Really? I'd think that routing things through subclasses of AbstractAction and then hooking them up as Listener to the various access methods would make it comparatively straightforward.