I think it's a excellent idea; in fact I think it's long overdue. The only minutiae suggestion I'd have would be to use disclosure triangles instead of +/- elements; or even to use the open-book vs. closed-book icons we have for the help files. If you're wondering what disclosure triangles are, here is an article. I'd prefer them over +/-, they're slightly less ambiguous, and slightly more intuitive: http://wiki.jrmediacenter.com/index.php/Disclosure_triangle
On May 20, 2009, at 2:46 PM, Eric S. Raymond wrote: > One of the flaws in Wesnoth's UI is that afyer you've been playing for > a while, the load-game dialog tends to list huge piles of autosaves > that are no longer really interesting; almost always you want to > reload the most recent save in a campaign. > > About 18 months ago I floated a proposal to change the UI for loading > savegames so game saves are grouped into threads. Typically a > thread would > be a sequence of saves that are a continuous history of a campaign, > though deleting saves in the middle could break a campaign into any > number of disjoint threads. > > The UI would then turn into a two-level interface. Normally all you'd > see would be a list of the most recent saves in each thread; there > would be a way to descend into threads and see all saves in them in > the relatively unusual case that you want to go back in time within a > thread. > > I am ready to implement this feature. In fact, I already have the > machinery for the lower half working in trunk. Thanks to YogiHH's > cleanup of the savegame code, I have been able to implement a "parent" > field in savefiles. Code can use these to run back down the ancestry > chain from any given save. Savefiles with no parent are thread roots, > usually the first autosave of a campaign - but as long as you have old > savefiles without a parent field in them, all of these will also be > treated as thread roots. > > Furthermore, I have working code in dialogs.cpp::load_game_dialog() > that inverts the parent relation, creating a parent_to_child map. > Savefiles with no child are thread tips and usually the files users > will be interested in reloading. > > This is all the infrastructure needed to support an improved, > thread-aware load-game dialog. The question, now, is what to do > with it at the presentation/UI level. > > Here's the approach I favor: > > Make the load dialog look something like a file manager, with > thread-tip saves behaving something like folders. That is, each > save gets an icon to its left. The icon may be > > 1. Blank, indicating a non-tip savefile > > 2. "+" (or variant) indicating a tip save for which all the ancestors > are visible in the list. > > 3. "-" (or variant) indicating a tip save for which ancestors are > not shown. > > The default presentation would be to show only tip saves, all marked > "-". > If you clicked on a "-", it would change to "+" and all the ancestor > saves associated with this tip would be displayed. If you clicked on > a "+", the ancestor-save lines corresponding to that that tip save > would be removed from the visible list and the icon would change to > "-". > Clicking on a blank would have no effect. > > Obviously this means the save list would have to be refreshed > whenever a - was toggled to + or vice-versa. > > Less obviously, I think this facility would make both the > sort-by-name/sort-by-date toggle and the filter box pretty much > pointless, and they should probably be removed to simplify the code > and the UI. > > Comments? Criticism? Technical issues? Alternate proposals? All > offers of help cheerfully accepted; I'd really rather not write more > C++ than I absolutely have to. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> > > The right of self-defense is the first law of nature: in most > governments it has been the study of rulers to confine this right > within the narrowest limits possible. Wherever standing armies > are kept up, and when the right of the people to keep and bear > arms is, under any color or pretext whatsoever, prohibited, > liberty, if not already annihilated, is on the brink of > destruction." > -- Henry St. George Tucker (in Blackstone's Commentaries) > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
