So for those on Mac, who actually likes the “Testing” panel vs the “Skein/Transcript” panel on Windows?
I ask that seriously although my tone probably makes it clear where I stand.
It’s not clear at all why the change was made. The “Testing” panel seems like a huge step backward, unless I’m missing something obvious. Also, from what I can tell, you can’t annotate or label in this new version. (That also seems to impact generating a solution as part of the release, because it reads annotated lines in the Skein.)
Given that the IDEs are written by different developers than the Inform developers, is this a case where each implementor can make these kinds of changes independently? (Answer is obvious, I guess.)
As a note, the documentation shows the Skein / Transcript but the Mac no longer has that functionality. The documentation does seem to be generated differently for the platforms based on little nuances so I’m wondering if the fact that the documentation hasn’t been updated means that this was just something being tried out versus “the new way.”
Nothing to offer here beyond (1) wondering why the change was made, (2) what was the general feeling of the community regarding both approaches, and (3) – pending thoughts on (2) – how do we have input into these kinds of design choices?
Just in case I was wrong about annotating, I tried to release with a solution (using the *** as best I could, which was via "edit a command). The error Inform reports is:
Error: no threads in the Skein have been marked ‘***’
So it seems like this overall feature of the “Testing panel” – if such it can be called – was released half-baked, without consideration of existing functionality (including error messages), and certainly without documentation reflective of it.
It would be great to hear from the Inform 7 Mac IDE developer as to what the rationale was and what the plan is. (I’m hoping the title of this thread is enough to catch the eye.)
I don’t think that the Inform IDE developers read this forum with enough regularity for this to catch their eyes. You could file a bug report about the annotation/solution being broken and link it back to this thread. I already made a bug report for the documentation still talking about the Skein/Transcript panels. The developers should see that… eventually.
Personally, I didn’t use the Skein/Transcript panels much, but when I tried to use the Testing panel recently I found it extremely confusing–I wasn’t entirely clear how to do the old bless/revise/compare thing I used to do with the Skein/Transcript. (It didn’t help that I was checking that a change in the code left the transcript unchanged; specifically, snipping the “now every thing is unmentioned” line from this didn’t change anything. Did you ever solve that infinite loop problem, BTW?)
Really, you should file a bug report about annotating/releasing along with a solution.* The developers do get around to looking at bug reports, the IDE developers work on a different schedule than the developer for Core Inform who often tends to sweep things up all at once at lengthy intervals. And if something in the documentation is actually broken then you’re warranted in filing a bug report, and they should look at it.
It certainly does seem to me as though there’s no way to annotate, which is a serious bug, as that not only breaks “Release along with a solution” in the way you’ve described but also makes it impossible to do some of the other stuff described in the documentation. I added a note about this to my bug report but you should definitely file a separate report, as my report is about the documentation not describing the way the IDE is supposed to behave while the issue you’re talking about is about the IDE not behaving the way it’s supposed to. And I suspect that the IDE developer is much more likely to see a bug report if it’s filed as an IDE bug rather than a documentation bug.
One thing about this is that the development is being done as a non-commercial effort by people who make their livings other ways, which does mean that they don’t always respond on a very rapid schedule. And it seems that the core-ish developers often spend their time processing feedback rather than responding to feedback. This isn’t supposed to be a judgment either way on how they do things, just saying that it’s unlikely that the developers will respond to a posting on here. The mantis and uservoice forums are the official ways to give feedback, though again, what’s more likely to happen is that they’ll see what you’ve said sometime rather than that you’ll get a quick response.
*For non-bug suggestions, there’s a uservoice forum, but that’s been a bit moribund.
Yeah, I’ll write up a report on that particular aspect.
As far as the non-commercial / hobbyist aspect, I completely get that. I work directly on SCI Companion (the new one; SCI VGA) and Adventure Game Studio. I’m also a core contributor to the LucasArts Jaguar engine (cost solution, but all volunteer behind the scenes). So I know how it goes. But it’s also the case that if you provide something to the world, you can’t be surprised when people want you to interact with the community you provided it to. But I also agree people in the community have to moderate how much they expect. (We had much more of a problem with this in the AGS community until we open sourced the entire engine, which democratized much more of the design discussion and still let us retain core committers.)
In this case, “the core-ish developers often spend their time processing feedback rather than responding to feedback” – that’s more what I want to see. What was the feedback that was processed around this particular feature? Particularly since it caused a divergence in two of the IDEs (not sure about Gnome/Linux) and caused a breakage of one piece of functionality and a complete disconnect in documentation. Generally processing feedback also means responding to feedback so that you have a bit of a dialogue, even if it’s not all the time.