[Jointly written response.]
Although we'll eventually address all of the points made in the last several posts, we'd like to focus on the FRED launching question for now. The other issues are long-term questions whose implementation will require much more work, and we don't anticipate having the time to do that in the near future.
However, we'd like to comment on the question of adding new launcher features. GUI applications meant for a general audience like wxLauncher don't benefit from having more and more features added to them, since piling on features in the absence of a larger, coherent vision for the UI as a whole is liable to result in a muddled and confusing UI, even if one consisting of arguably useful features. See items 1 and 2 from these
Windows User Experience Design Principles, for example. For more information, take a look at the other design principles articles available from that page's left sidebar and also
these three articles on common sources of usability problems in open source software.
We're primarily coders, not UI designers, and we'd love to bring on board someone with a strong UI design background to take the role of lead UI designer and help us shape that vision for the UI, but until that happens, we'll have to be fairly cautious about what features get added. This is not to say that new features won't be added; rather, proposed features must, at a minimum, provide a large benefit to a very large part of our user base. Some form of assistance with troubleshooting would certainly qualify.
Now back to FRED launching.
While it's true that a sizable portion of the modding community uses FRED, only a small fraction
of our entire user base uses FRED. It becomes a tiny fraction once you include all of the people who come to play one of the TCs. Normally, a feature that benefits so few people would likely have never been added in the first place (see the principles article above), but since we recognize that FREDding is crucial to the community and that FRED launching is valuable to those who use FRED, we have chosen to include it.
But given that the vast majority of wxL's users will never use FRED, we consider it bad practice to subject all users to the added clutter of the FRED launching controls. Yes, even just three controls are clutter for someone who will never use them, especially for someone who is just trying to get started, particularly considering the wide range in our users' level of computer savvy. Moving the FRED controls to a new tab not only does little to eliminate the clutter but actually creates an even
bigger problem by moving the controls from where they should logically appear, thereby breaking consistency.
Yes, the current method of enabling FRED by editing a text file is a pain and needs improvement. That's part of why the launcher is still not at version 1.0. We'd like to point out that anyone who finds locating and editing a text file to be difficult will likely find FREDding to be overwhelmingly challenging.
We are aware of the objection that not having FRED launching available by default unnecessarily adds a barrier to FREDding, but consider that FRED launching is in no way essential to using FRED. Countless FREDders have gotten by without this feature while using the Windows launcher. The real barrier to FREDding is the complexity of making missions and of FRED itself. Making FRED launching available by default will not change that.
Put another way, wxL was intended from the beginning to not only unify the launchers for all supported platforms but also be less intimidating to new and casual users, thus we disable and hide little used features by default.
Thus in our view, FRED launching belongs as a feature accessible through an advanced options panel. While FRED launching will currently be the only option available on this panel, we have no doubt that more advanced features will eventually be requested, and options to enable them will be added there. Because we haven't had time to create this panel, the current clunky method will be the only option for the moment, but we now have a
bug ticket to keep track of this.