I’m not volunteering (yet), but could you point to a couple of small-ish TADS or TADS-related fixes that a newcomer to the project could tackle?
For example, I see this one (“Some TADS grid windows have incorrect background color”), but don’t actually know if this is a good patch for getting one’s feet wet.
Hopefully this would also not get buried in the search engine results…! 
That’s the main concern I have, honestly.
Just because you’re not seeing such ownership doesn’t mean there haven’t been pushes. I’ve personally been trying to poke at this multiple times, but the capabilities/structure of Glk are a bit opaque and it’s very difficult to find centralized information on what’s going on with this API, and learn how to bridge HTML TADS with it. I’ve been circling around another attempt at it recently, and have been gathering previous notes I’ve collected here.
At this point, the way forward could even be clearer and easier if there was development of a separate online interpreter for TADS, which uses MJR’s specifications and documented webapp APIs, because the barrier to entry might lower and there are fewer constraints involved. Sure, it might not benefit the Glk sphere, but that could be what the TADS community taking ownership and initiative looks like. 
Similar to QTADS being developed as a specialized cross-platform interpreter.
I don’t know which things would be small. I suspect most would actually be fairly involved, which is part of the difficulty as we really people who are quite knowledgeable about the interpreter codebase.
Colours could be largely fixed now in Gargoyle, though for Parchment will have to wait for my Rust port of RemGlk to be finished. If someone wanted to do the colour support now that would be great!
(Also when I say Gargoyle, include Spatterlight too as it should have equivalent support.)
I would hate to see a concerted effort to move further away from a universal interpreter, and I could also point out that move would certainly sacrifice some fraction of audience for TADS. Before we press the nuclear option button, could we discuss, specifically, what is needed to bring these options to Parchment, etc.?
Also, if it’s a matter of resources and hours of labor, perhaps this might be a good initiative for the IFTF grant program? A proposal to identify and target TADS modernizations of the glk interpreters seems like it would certainly benefit the greater community.
One point I haven’t seen mentioned yet is the state of screen-reader support for TADS.
It is my understanding that if a title uses HTML-TADS, the screen reader is not supported by QTADS on Linux or Windows (and probably Mac?).
As far as I’m aware, right now, the only interpreter that can run an HTML-TADS game with screen reader support is the interpreter also called “HTML TADS”, and it’s Windows-only.
That means, even if somone were willing to ignore the play online feature, they would not be able to play an HTML-TADS game offline with a screen reader on a Mac or Linux machine, or a mobile device, like Android.
If we can make sure HTML-TADS has expanded support through Glk, then as a bonus, screen reader users can have sound cues and music in their TADS games.
I guess I’m just pointing out this gap goes beyond convenience and encompasses accessibility issues as well.
Right now the problem can be seen with the following:
The people in the TADS community are knowledgeable in TADS. The first hurdle is learning specifically how the documented VM works.
The second cliff face of a hurdle is that there are very few centralized sources of info on Glk, what it is, how it works, what its limits are, the current state of the Glk implementation of HTML TADS, what has been implemented, what is missing (using MJR’s work as a template), contribution standards and protocol, and more that i haven’t even gotten around to yet. Just trying to figure out the tech stack took me reading through multiple sources and asking around.
This is a jarring mess of confusion to ask volunteer TADS devs to wade through and contribute to your codebase. The only known solution that I have found for someone wanting to join in is staring at the complete volume of C++ code until it finally makes sense, and there’s no telling how long that could take a volunteer team of new contributors to tackle.
For instance, what if a volunteer finally gazed at MJR’s VM code and the Glk code long enough to finally understand them, and then discovered a fundamental incompatibility between the two? A new volunteer has no assurance that this isn’t a problem that is waiting for them, much less where to start.
EDIT: Found Glk info. Crossed out stuff accordingly.
Unz, IMVHO Qtads remain much better than gargoyle TADS 'terp…
from the (non-HTML) TADS3 version of my “scroll of style”:
style markings:
<b> ... </b> - display text in bold (all three, frob, tadsr and qtads)
<i> ... </i> - display text in italics (only qtads and tadsr)
<u> ... </u> - display text underlined (only qtads)
<FONT COLOR=RED> ... </FONT> - display text in red. (only frob and qtads)
(tadsr is actually gargoyle-tads)
But I reckon that my need for an extended gamut of styles is for conveying in English tone/pitch/nonverbal nuances of Italian…
Best regards from Italy,
dott. Piergiorgio.
Which is fine for the fraction of your potential audience likely to use it over a play-online option.
Many of the players are barely aware that there are different interpreters. All they see are IF games. Increasing interoperability and accessibility in general is a Quality of Life improvement for players. Indirectly, everyone benefits.
Approaching this as a TADS vs Inform thing is… not great.
Unless someone more eloquent wants to interject, I’ll start working on an IFTF Grant proposal to do three things:
1.) Identify interpreter gaps and suggest potential fixes.
2.) Identify lapses in documentation amongst TADS and Glk.
3.) Create a proprosal for a paid job to tackle these these things, to be entertained as a second step by the IFTF Grant Board.
Hopefully this would set things up for a clear identification of the problem and it’s extent. It would also set up at least a token consolation payment for the individual(s) who ultimately spend the many hours needed to address these problems, alleviating, somewhat, the martyr issue.
Also, there is a growing trend in the next generation of IF players where offline interpreters aren’t even seen as a valid option for play. Nevermind TADS vs Inform; if there isn’t an online presence for any IF system in the coming years, it’s probably going to take a massive hit.
TADS has the opportunity and flexibility to support games that go beyond the parser/choice divide and even extend beyond it, but any game that tries to break the mold currently outlined by Parchment will simply fail to function, and won’t even have an error report to say that something went wrong. These games will just be met with confusion and buried.
I’m sure the TADS community would be happy to volunteer and take ownership but we need help at the on-ramp to even get our bearings for where to start.
This would be huge. Thank you!
Echoing this question. When I’ve looked at writing in TADS on a Mac in the past it was not good. I’m glad things have improved. But I don’t think this knowledge is widespread among Mac IF authors. Even running TADS games was problematic for me until not so long ago.
Tomas released the Mac/Linux IDE extension about 1.5-2 years ago?
So really recent. And yes I could easily have missed that news - have been phenomenally ill the last few years,
But I’m really delighted this exists. I will check it out. Thanks for the heads up!
I gently suggest that, in regards to the TADS online play problems, there is strength in numbers and unity. I would rather see improved TADS support in Parchment et al. than a separate browser-based solution in need of its own maintainer(s) and release cycles.
TADS support with existing browser solutions are (taking a wild guess) 70% there? That means an additional 10% of improvement might get almost all TADS games in a fully supported place? (Which is to say, the high majority of TADS games don’t use graphics or sound.) That sounds like a good deal to me.
A micro-grant seems like a great idea. Another possibility for IFTF (if they’ve not already explored it themselves) would be to apply for a Google Summer of Code intern.
I’ll roll that in as a possibility in the proposal.
Wholeheartedly agreed.
Hopefully the grant can help install some signposts and lights for the codebase and consolidate some necessary information and wisdom. (If it goes through, of course)
I would’ve thought that full HTML TADS compatibility would matter less for screen reader users (though partially sighted users do deserve the best of both the visual presentation that HTML TADS offers, and solid screen reader support.) Screen readers should support the console mode terps including Parchment and Lectrote.
Does TADS have alt-texts for images, things like that? While not impossible to implement in Glk TADS, that would be more involved.
This seems backwards to me - info on Glk is very centralised - there’s one very well written specification, and then for questions most of the Glk library authors are here on this forum.
But yes indeed, the difficult side is the Glk implementation of HTML TADS, how HTML TADS works, etc. That’s not really decentralised as much as almost non-existent. Other than MJR has anyone other than @RealNC even written an HTML TADS implementation?
Sure, it is a big ask. Just be aware that it’s an even bigger ask for non-TADS devs to do, which is how it feels whenever I see people bemoaning the lack of TADS features in Parchment.
There isn’t a fundamental incompatibility, or else we wouldn’t have any form of Glk TADS now. And I’m pretty certain we can add a lot more support for HTML TADS, but it will be incremental support, not complete support.
The TADS community needs to provide its own on-ramps, there’s no one else who can do it. I consider myself a fringe member of the TADS community, but at the moment the most I can really do is point you to this document: Notes on porting HTML TADS
Sorry, but I don’t think that’s how it will work. Firstly, it’s much more like 25% right now than 70%. There is support for the Banner system, but almost no formatting. And further progress will be incremental rather than all at once. (Though like most things, the 80-20 rule applies. There will probably be a point where Glk TADS can switch on most of HTML TADS, but some things may never be possible in Glk TADS.)
If this all gets done, is understanding .z6 files ever to be accomplished (since Gargoyle can only understand text and refuses to use pictures or windows from v6 z-machine games), or am I being unrealistic?
As an outsider looking in, I don’t understand why this has to be the case. Identifying the gaps and creating an incentive beyond altruism for someone to address it doesn’t necessarily mean you or another non-TADS dev would or should be the ones ultimately doing this work. Ideally, it wouldn’t be, for the several reasons you pointed out above.
But if we don’t take the time to clearly delineate the problem and the specific steps needed to address it, we’re left with a fairly open-ended and ambiguous prospect, which makes it an even bigger ask for any potential individual.
Appropriately or not, your past experience and work on Glk interpreters in general, and wider community awareness of your skills specifically, make you a logical focal point to address concerns with Glk implementation. I’m also sure, superficially, many folks would love if you could somehow wave a magic wand and just fix this; you aren’t wrong there. Yet, we both know reality doesn’t work that way. This will take real work and time, and gains will be incremental, as you stated yourself.
I, for one, do not expect that you should martyr yourself on this hill. You already do an immense amount of work, entirely pro bono, for the IF community; more than most folks realize, to be honest.
With that said, getting anything done, especially difficult things, requires awareness, and organization, and a general mandate that something should be done. All of this needs to occur before we can even start to identify who might be both well suited and also willing to do this. You can’t get any of that done without some amount of “bemoaning.” I’m hoping by nailing down the specifics of the ask and providing a little bit of incentive, even if mostly token, might coax one of the more skilled semi-retired TADS folks to consider the project.
I gently suggest we perhaps focus on figuring out the scope of the problem and the best avenue for attack first, and leave who will do the attacking for later deliberation. Which is why I’m working on a grant proposal right now that might provide some funding to task a willing individual to do just that.
Very unlikely. It might be possible to have some Z6 support, but there’s unlikely to be enough demand to warrant the effort, considering that pretty much everything Z6 can do, Glulx can do better. (In isolation, not necessarily in conjunction. That would be the difficulty in trying to implement Z6 in Glk - if a Z6 game requires some kind of pixel perfect window quirk then it’s unlikely to be possible in Glk.)
Maximising Glk Z6 support would really have to be done by an Infocom ultrafan. Otherwise, non-Glk Z-Machine interpreters are the way to go for the few Z6 games that exist.