Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lyubomir]

I have published "nestgrid" novel quasi-xml user inteface framework that has a whole bunch of useful features, like
- extensible text representations of model objects with easy to change attribute schemas and context sensitive command execution
- direct manipulation of items by user in quasi text editor
- minimal programmer effort in terms of programming the ui, i.e. no endless layouts of ui widgets

The article with screenshots and linked demo is at http://nestgrid.org . In particular, the demo is here http://megaswf.com/file/2569831/

I have been thinking that this sort of interface is ideally suited to the complex, highly nested and frequently changing schemas representing Dwarf Fortress objects. And, because of the inherent programming ease of implementing ui for such objects, perhaps Toady One would be interested in using it in DF.

At present the codebase is released under Affero GPL, but I would be happy to provide a free or low cost commercial license specifically for DF if there is interest.

[JanusTwoface]

If it's in ActionScript though, how much work would it take to bind to a C/C++ codebase? Honestly, I'm not sure. It seems like the kind of thing that could be done, just that might take a fair bit of effort.

Also, the aesthetic is completely different from what DF has. Easily configurable UI engines aren't *that* rare (6 million hits on Google for 'SDL gui'), so it's mostly a matter on if Toady will ever get around to it. And when he does, it seems like he might be able to find one that matches better with a pure ASCII interface (although it probably wouldn't hurt if he could move past that particular requirement).

Finally, there's the issue of Toady depending on an external library. That's the main reason he's given in the past for wanting to keep development 'in house' for the time being, eschewing any sort of API or external UI code since every time he makes breaking changes, anyone writing extensions has to update their code as well. If they've moved on, things will break and Toady will be blamed (even if subconsciously). I don't know if it's the best argument, but for the moment at least, that seems to be how it is.

Also, what is the Affero GPL? I looked it up (linky), but it's crazy long compared to the standard GPL. And the first sentence (... specifically designed to ensure cooperation with the community in the case of network server software) makes it seem like a strange choice for a GUI framework. Is it as viral as the standard GPL when linked against? I'm pretty sure that would be a no-go right there.

[King Mir]

So you have an xml based language and tool for writing widget based GUIs. Dwarf Fortress isn't build on widgets. It's built on a grid. So your tool is useless for it.

[Beyondrepair]

@^ King Mir: I can assure you that it's possible to integrate a GUI library on top of DF's current rendering and reduce reliance of "the grid" to rendering the map.

@ OP: Not going to evaluate this library in this thread (might have a look at it for my own stuff ^^), but there are plenty of GUI libraries that in theory could be integrated with DF in SDL/OpenGL (like, in the hundreds). Presumably Toady has evaluated more than a few and turned them down for his own reasons. I'm not saying he's doing the right thing, but it's kind of useless lecturing him about it. He seems intent on the "develop game before sanitizing the GUI" focus.

[lyubomir]

thanks for the responses. Here is my IMHO about some of the points raised

RE JanusTwoface:

1. the issue of porting AS3. The codebase is about 10KLOC and is (mostly) independent of flash specific widgets. In practice maybe several of these KLOC might be shaved off if some of the more "specialized" features are not ported as irrelevant. It's essentially no dependencies code mixing OOP and functional style / array comprehension coding styles. I am not sure how easy that would be to port to "DF version" C++ (which is probably a sui generis environment / virtual machine) but porting to Javascript, Perl, Lisp or any other interpreted language with widely available interpreters wouldn't be real hard. But yes, up front, I do recognize that this is a very valid point about a complex issue.

2. to compare nestgrid to "SDL gui" as both being "easily configurable" is to miss the point of nestgrid. Nestrid is *a lot* easier configurable than anything involving WIMP widgets. Incidentally, another aspect to the ease of configurability is that the likely application of the technology to Dwarf Fortress would allow easy configuration/configuration not just by the programmer but also by the users. Nestgrid allows creation of custom menus / todo lists / "reports" just by rearranging "lines" in "document" so depending on circumstances the user could have references to specific high value dwarves or projects "near the top" at his fingertips, as well as notes about them, dashboard progress info, links to related items etc. Nestgrid could also easily support free-form search through the objects it represents, e.g. both search for dwarves with certain features or for commands with certain names.

3. RE GPL license, the codebase belongs to me and is dual licensed - under Affero GPL and under anything else that I feel like releasing it under. The cost for the commercial license is still vague (nobody asked for it ) but it would be quite finite, and quite possibly $0.00... I do realize that Toady One wouldn't incorporate GPL code, obviously.

RE KingMir:

Dwarf Fortress is not built of "widgets" but it *is* built of objects. Dwarves, animals, traps, rooms etc are all objects with attributes. Nestgrid allows an easy and infinitely extensible way of making user interfaces for representing and controlling such objects. That's what nestgrid is all about

RE BeyondRepair:

yeah, I know about widget libraries and Toady One's decision. I just figured that because of inherent superiority of nestgrid to widgets for representing Rogue-like games and interfaces he may change his mind.

Or even if he doesn't, maybe somebody else would be interested in nestgrid or quasi-nestgrid interface for Dwarf Fortress mods. Unfortunately I myself don't have much understanding of how DF mods, ERPs and other wrapper thingies work at this point, i.e. what they can and cannot do, how they do it etc.

[King Mir]

@^ King Mir: I can assure you that it's possible to integrate a GUI library on top of DF's current rendering and reduce reliance of "the grid" to rendering the map.

Why would you want to? It would prevent text mode, for one. It would be good it DF truetype text display was smarter, but otherwise the gird is part of the flavor of DF.

Dwarf fortress does need a better UI, but getting rid of the grid system, even in menus, is not needed. Using this tool would not solve a problem that DF has.

[King Mir]

RE KingMir:

Dwarf Fortress is not built of "widgets" but it *is* built of objects. Dwarves, animals, traps, rooms etc are all objects with attributes. Nestgrid allows an easy and infinitely extensible way of making user interfaces for representing and controlling such objects. That's what nestgrid is all about

A container of objects with attributes is a trivial thing, and isn't a UI thing. Your tool seems to be a UI tool, so the question is what advantage does your tool provide in displaying those attributes? And if Toady is to consider using those tools, what deficiencies in DF does this tool overcome? DF is a mature project, so even if you're tool would help a project like DF if it were used from the start, the problems it seems to help with already have solutions in DF.

While your tool does have use in other contexts, it doesn't seem like it would enhance DF.

2. to compare nestgrid to "SDL gui" as both being "easily configurable" is to miss the point of nestgrid. Nestrid is *a lot* easier configurable than anything involving WIMP widgets. Incidentally, another aspect to the ease of configurability is that the likely application of the technology to Dwarf Fortress would allow easy configuration/configuration not just by the programmer but also by the users. Nestgrid allows creation of custom menus / todo lists / "reports" just by rearranging "lines" in "document" so depending on circumstances the user could have references to specific high value dwarves or projects "near the top" at his fingertips, as well as notes about them, dashboard progress info, links to related items etc. Nestgrid could also easily support free-form search through the objects it represents, e.g. both search for dwarves with certain features or for commands with certain names.

This requires Toady to design a public interface for the objects displayed by the GUI. Toady has said he does not want to maintain such an interface, in part because public interfaces are harder to change, and in part because he wants to discourage tools that people consider essential, which Toady would feel pressured maintain comparability with.

Also, as a public interface to the menus, this tool does not make a good drop in, because it would require a rewrite of the GUI.

[lyubomir]

King Mir, first of all, I never proposed in this thread to abolish the spatial grid. I do propose that nestgrid based interface equivalent to DF menu system would be much more convenient / powerful / easy to use / etc. To the extent that the spatial grid may intersect it, it could be possibly via introduction of places as objects referenced in the nestgrid, e.g. the "near the river" place; since such places are just an arbitrary collection of squares subjective to the user and don't seem to have built-in DF representation, they would likely be specified / deleted manually as needed.

The question "how is nestgrid any better than DF menus grid, or WIMP widget screens, or other familiar ui patterns" IMHO belongs to the same class as "how is the first html browser any better than a collection of newsgroup pages with text references between them" or "how is the first wiki better than editing webpages in Notepad and uploading by ftp". The answer to such questions is, the more inherently powerful and aligned-to-the-underlying-data-model interface is generally superior in the long term; likewise, free-form easy to customize interface is superior to fixed, bend-the-user-to-its-will one; but if you are looking at it not at the time it has matured and won out but rather in the beginning of the system's S-curve lifecycle, understanding the mechanism of how the new system is better than the old takes some thinking/insight. In practice, right now I don't have the bandwidth to produce feature-by-feature explanatory paper comparing existing DF ui with possible nestgrid implementations; all the more so given that I am not very skilled with DF in the first place. That certainly shouldn't stop you, if you are actually interested in the matter, from rereading my answers here in the thread and the original publication and thinking about the potential benefits of being able to construct / continually alter as needed your own "menus" / object lists / interfaces and search through them by attributes instead of being restricted to the relatively fixed setup in DF proper and the somewhat more fluid one in Dwarf Therapist.

Looking towards the future, I think at this point that the most likely way in which nestgrid principles might be introduced to DF would be as part of a standalone addon similar to Dwarf Therapist; with interaction to the main game either via memory injection or screen scraping and programmatic sending of hotkeys. Interestingly, since nestgrid relies on user-edited, loosely-specified schema, this hypothetical addon would be less brittle than DT with respect to the underlying game model change over various DF versions; this is just part-and-parcel of what makes the more free-form, human-edited nestgrid different (and better, for many situations) than the rigid WIMP interface dependent on data schema consistency.