Hrmmm. I've been digging around quite a bit, and I haven't found a C++ gui library that I like yet. SDL has been the most promising yet, but I'd rather not build an entire UI toolkit from scratch. Qt forces you to use their own compiler and toolchain and is a massive install, and distribution is really tricky. GTK is a clusterbomb of dependencies and crazyness. I'm considering just writing the GUI frontend application in Java, or something with a cross-platform UI toolkit built in (because eww java), and just boot off my C++ executable process when the "invoke" button is pressed.admin wrote:IMHO, for the UI bit, try keeping UI and functionality as seperate as possible, so that you can 'skin' the core of your aplication any way you want at a later stage. The actual process should, again IMHO, respond gracefully to aborting *at any time*, output an error code if aborted and, while running/doing its thing, output some sort of meaningful message to the host (UI) application that represents a 'progress report', which the host application can then relay in any way it sees fit to the user (e.g. a nice progress bar). The strategy is 'start ugly', make it work, and refine the interface as you go along.
First and foremost, you're tangibly improving people's joy in the hobby by making it easier to obtain better results for more people than ever before. Don't underestimate that impact!
Again, KISS - keep it simple, stupid. Do a few things and do them well. Expand later.
In application and UI design, apply the 80/20 rule, which goes like this; optimise your application for the 20% of functionality that people will be using 80% of the time when they fire up your application. If any stuff in your application doesn't fit the 80/20 rule, you hide it in a sub menu, some preset button or give the user some other means to accomplish the 'more exotic' task.
Apart from delivering better results, don't underestimate the need for convenience. If some core thing/process takes too much time/clicks to accomplish, you'll lose users (e.g. why should they use your application over, for example, DSS?).
Given the state of some of the stackers out there and the strong evidence that people struggle with these applications, you have a lot of leeway to improve the state of the art.
There's one idea floating around in super wishful land, though. I have no idea what StarTools looks like on the inside, or if this is even remotely possible, but I figured I could throw it out there anyway: A StarTools plugin system.
Basically, I would make a .so/.dll plugin that StarTools would load with dlopen/LoadLibrary, and then it'd be something like another button on the home screen dynamically added via the plugin that says "Stack". The huge upside to this for the end user is that there are no intermediate files, *and*, the whole standard deviation second file wackyness is completely hidden from the user (well, maybe informing them it exists and stuff) - the data would go right to what looks like a "normally opened file" with tracking enabled. The huge upside for me is that I might be able to re-use some of ST's GUI widgets (sliders, progress bars, file open window, etc.) instead of doing it all myself
) Seperate logic from your UI. At the end of the day, that's what happened with dcraw as well - so many front ends for that (including web-based ones)! Someone else will come along to build a 'better'/different front-end (including StarTools and/or The GIMP!). Get the logic and real magic working first!