Beta Address: http://blish.org/sdrdxdoc/designnotes.html
8 - Design Notes
Menus: You'll probably notice that although CUTESDR used menus for various functions, I don't (although I've not removed any of CUTESDR's menu operations.)
This is because on a Mac with multiple monitors, the menu is often way the heck off on another display, and so becomes quite inconvenient to use... furthermore, if the application isn't active, you have to go click on it or use ⊗ TAB to otherwise activate it, then go find the menu on the other display. The Mac menu system is poorly thought out. It's one of the few really serious Mac GUI design flaws. So I prefer not to use menus.
Instead, I put controls on the application's window, and I try to provide keystrokes for most common operations as well, as for those users who take the time to learn the keyboard commands, operation is much faster. You can, of course, just use the GUI.
Window width: I'm trying — hard — to keep the minimum window width about where it is, under 1280 pixels. This is because if I go any larger, there will be a whole swath of monitors that the application will no longer fit on, and that's a bad thing. As of v2, r00 I have replaced most of the Mac GUI elements with custom, auto-resizing ones that can take up considerably less room when the application is open in a smaller window. This will allow more controls to be added in the future.
Bugs: I try to keep bugs to a minimum, and I welcome your feedback — certainly I make mistakes — but please be aware that this application is NOT a native Mac or Windows application, it is developed in Nokia's "Qt", not Apple's XCode or Microsoft's various development tools.
Consequently, everything that works with OS X or Windows is done indirectly by calling a Qt function. When Qt gets it wrong — and they do — not only will bugs show up, but I may have no way to fix them until or unless the Qt people do, and even then, that requires I update the development system, which can break other things that were working fine. It really is a problem.
One example of this is the Mac file dialogs, where technical users will note a series of error messages on the system error console when the file dialogs are opened from SdrDx. I'm doing it the way the Qt people say it should be done, but... there the errors are. They seem to be relatively harmless, but still.
Another example is the FUNcube Dongle support for Windows. Under OS X, Qt allows me to open a sound card with a sample rate of 96 KHz, which is what the FUNcube (optimally) requires. But under Windows, any attempt to open a sound card at a rate higher than 48 KHz results in failure because the Qt Windows runtime refuses those rates. This means that the FUNcube works a lot better under OS X than it does under Windows, and it's nothing at all to do with how I wrote the support — it's purely a Qt issue. I've submitted a bug report to the Qt people, identified the problem code for them, and even asked the Qt community at large to help modify the framework, but so far (it's been years now), nothing.
So why use Qt at all? Simple: Because it allows OS X and Windows support from one (mostly) unified codebase. That single advantage is worth quite a bit of inconvenience to me.
| toc | index | guide | changes | keyboard | , previous | . next |