using Inform 7 IDE
Warren
to fully see it and play around with it in the IDE but it's virtually
impossible to keep track of anything as you go. I can't imagine writing a
full length game like this, compared to how you could do things in Inform 6.
I know I can look things up in the Index, but sometimes that takes just as
much time as doing a search. Here's a scenario:
First I have to flip to the Index tab from my Source tab. You can't use
CTRL+TAB like most ever other Windows app so I have to remember to do F6 to
switch sides, since I don't want to lose my Source tab. Then I may (or may
not) have to press SHIFT F6 (for the Index panel; I can't go backwards so I
have to go forward all the time) and then hit CTRL F6 for the any subpanels
in Index. Then I get to try to figure out what Index tab is the one I want.
Then I have to scroll through those contents to find what I hope is in
there. Then I have to click an icon next to that to get taken to that part
in my source code.
Can someone explain to me how this is an effective IDE or what you do to
make this cumbersome process easier. Is there literally no provision for
breaking up the story into multiple files or something? I don't get how this
is supposed to be like a book. No book I ever read is composed of one
gigantic page. Inform 7 looks really cool on the surface and when you're
doing simple examples, the Index is really helpful but when you do something
big I'm finding the interface starts to work against you at every turn.
mikegentry
Warren wrote:
> First I have to flip to the Index tab from my Source tab. You can't use
> CTRL+TAB like most ever other Windows app so I have to remember to do F6 to
> switch sides, since I don't want to lose my Source tab. Then I may (or may
> not) have to press SHIFT F6 (for the Index panel; I can't go backwards so I
> have to go forward all the time) and then hit CTRL F6 for the any subpanels
> in Index. Then I get to try to figure out what Index tab is the one I want.
> Then I have to scroll through those contents to find what I hope is in
> there. Then I have to click an icon next to that to get taken to that part
> in my source code.
I don't know, man. I do pretty much the same thing, except I tend to
describe it like this:
"First I have to open up an Index tab, which I do by clicking on the
appropriate tab with my mouse. It took a little exploring and practice
to remember what's in each tab, but since there's only 7 tabs and most
of them have intuitive labels, it's not really a problem anymore,
especially since 90% of everything I need is accessible through either
Contents or World. Then I scroll through the contents, which, since I
organized all the headings and subheadings myself, is exactly as
intuitive as I need it to be. Then I just click on where I need to go."
Maybe it's easier (at first) to navigate through something you've
written yourself, rather than someone else's completed source code? I'm
able to use the IDE without hardly thinking about it, and my source is
quite a bit larger than Bronze.
Warren
news:1167584036....@k21g2000cwa.googlegroups.com...
>
> "First I have to open up an Index tab, which I do by clicking on the
> appropriate tab with my mouse.
That works great --- if you like switching from keyboard to mouse all the
time. But when I'm in a writing mode, I like keeping hands on the keyboard.
Most programmers I know do. (I know --- with Inform 7 we're no longer
programmers, we're authors; we should just drop all these conventions that
have existed in just about every other development environment out there.)
> especially since 90% of everything I need is accessible through either
> Contents or World.
That's good to know at least. If the usage of the various tabs can be
minimized, that will help.
> Then I scroll through the contents, which, since I
> organized all the headings and subheadings myself, is exactly as
> intuitive as I need it to be. Then I just click on where I need to go."
Yeah, I get this. But it's still a lot of scrolling. Again with that damn
mouse. It's easier to just do a search. If you've named everything
intuitively which I agree is necessary, that seems quicker.
> Maybe it's easier (at first) to navigate through something you've
> written yourself, rather than someone else's completed source code? I'm
> able to use the IDE without hardly thinking about it, and my source is
> quite a bit larger than Bronze.
Maybe it's just me. Personally I find having one huge file for everything is
just very annoying. I know you have the section breaks and stuff but those
quickly get buried, forcing me to go to the Index. I guess it's a love it or
hate it thing and you've got to decide which camp you fall in.
Jim Aikin
> files or something?
Is this the case? I can't imagine that you have to put everything in one
source file! I haven't played with I7 for a while -- can somebody confirm or
deny this?
--JA
Jeff Nyman
news:q9Tlh.30868$Gr2....@newssvr21.news.prodigy.net...
> Is this the case? I can't imagine that you have to put everything in one
> source file! I haven't played with I7 for a while -- can somebody confirm
> or deny this?
It's not possible to use multiple source files via the IDE unless you opt to
create your extra source files as extensions. All of your source is stored
in the Source tab, which corresponds to the story.ni file. You can use
multiple files (non-extension based) outside the IDE, however.
- Jeff
Jeff Nyman
This is one of the reasons why I've decided to abandon Inform 7 for now. For
me, it's too problematic to use it without the IDE (rock) but I've found the
IDE just constrains me too much (hard place). I still think the IDE has a
lot of good ideas in terms of interface presentation, but I also think
there's too much attempt to adhere to a metaphor. Having worked in interface
design and usability testing for many years, too much reliance on metaphor
makes me nervous about future development of a system unless the system has
provisions to be altered or allows the metaphor to be somewhat fluid.
A good example would be what you and Mike referred to. If it is, in fact,
the case that most users will spend most time in the Contents and World
sub-tabs of the Index tab, arguably those tabs should be closer together or
provisions should be made for moving tabs in a way that suits the user.
(That's how you do user-focused design: consider what will most often be
used -- and how -- and design accordingly. Or make the system customizable.)
The thing is that good interfaces are usually considered "good" by people to
the extent that they allow you to write (code) in a way that matches how you
think. (As just one example, Visual Studio 2005 allows you to choose between
different interface styles based on the *type* of development you will be
doing.) "Good" languages are like this as well, so so the theory goes: they
are designed to match how people think about a problem domain. Inform 7
appears to be trying to deal with both aspects. Time will tell how well it
has done so.
All this said, (1) the IDE is relatively young; (2) perhaps you can suggest
alternative approaches to the author; (3) the IDE itself is open source so
if you know C++ you might be able to do something about this on your own.
That said, your new version would be a fork of the build process since the
development cycle for this (to my knowledge) isn't collaborative in a strict
open source sense.
- Jeff
Khelwood
It's technically true, I think. You can split your source up and
include the bits as extensions, but that's not optimal because you
don't get the same feedback on errors in extensions as you do in story
source.
mikegentry
Warren wrote:
> Maybe it's just me. Personally I find having one huge file for everything is
> just very annoying. I know you have the section breaks and stuff but those
> quickly get buried, forcing me to go to the Index. I guess it's a love it or
> hate it thing and you've got to decide which camp you fall in.
I'm willing to accept this. I've never been a programmer and I don't
think the way programmers think. During development of the original
Anchorhead, I found splitting the source into multiple files to be a
huge pain in the ass. I like using the mouse and keyboard in
conjunction, because I hate having to learn hotkey combinations. Thus I
love the IDE. I never had any serious desire to return to IF until I
saw the IDE for Inform 7.
Emily Short
Warren wrote:
> "mikegentry" <mi...@edromia.com> wrote in message
> news:1167584036....@k21g2000cwa.googlegroups.com...
> > organized all the headings and subheadings myself, is exactly as
> > intuitive as I need it to be. Then I just click on where I need to go."
>
> Yeah, I get this. But it's still a lot of scrolling. Again with that damn
> mouse. It's easier to just do a search. If you've named everything
> intuitively which I agree is necessary, that seems quicker.
Generally I do navigate by search, myself; I don't find this
particularly slower than the process (with BBEdit/Inform 6) of opening
the correct file, then scrolling/searching within it for the material I
needed to change.
That said, if there are specific changes you think would streamline
things for you, please do feel free to send in your comments, and we'll
see if they're workable.
Warren
>
> I'm willing to accept this. I've never been a programmer and I don't
> think the way programmers think. During development of the original
> Anchorhead, I found splitting the source into multiple files to be a
> huge pain in the ass.
Yeah, but you didn't have to do this in Inform 6. You could used one
gigantic file if you wanted. So you were given a choice. With Inform 7, you
must use one gigantic file. You don't have a choice. Inform 7 might cater
more to people that have your preferences. I just wish it took into account
the many of us that don't share those.
Warren
news:1167592388.6...@n51g2000cwc.googlegroups.com...
>
> That said, if there are specific changes you think would streamline
> things for you, please do feel free to send in your comments, and we'll
> see if they're workable.
This works except it can become chaos. Is there any sort of design
discussion that goes on with the IDE? Since the IDE has to work largely the
same between Mac and Windows and since its different development streams, it
seems like any requests have to be gone through a bit more than just a
"workable" filter.
Emily Short
The definition of "workable" here involves having Graham, Andrew, and
David all sign off on the idea.
mikegentry
Warren wrote:
> Yeah, but you didn't have to do this in Inform 6. You could used one
> gigantic file if you wanted. So you were given a choice.
Not really. One gigantic file is unmanageable unless you have some way
to organize it. In Inform 6 you could do this by splitting it into
files. I hated doing that, but I didn't have a meaningful choice; it
was either that or deal with a mile-long, unindexed text file.
Inform 7 solves the problem a different way. It lets you create a
personalized system of headings, and then automatically generates a
hotlinked index by which to navigate. If you don't like that, you can
just search through the mile-long, unindexed text file -- which was
also your only other option in Inform 6. That's a different set of
choices, but it's not *fewer* choices.
Warren
>
> Not really. One gigantic file is unmanageable unless you have some way
> to organize it.
> In Inform 6 you could do this by splitting it into
> files. I hated doing that, but I didn't have a meaningful choice; it
> was either that or deal with a mile-long, unindexed text file.
That's not true. There were various IDE's that allowed you to do this with
Inform 6, like Imaginate, Visual Inform, JIF and IF-IDE. That was what was
nice: Inform 6 didn't force an IDE on you. You could also build these
navigation structures into other editors and only have it include the
information you wanted. You can't do that with Inform 7.
> also your only other option in Inform 6. That's a different set of
> choices, but it's not *fewer* choices.
Again, whatever works is cool for you. But you do have fewer choices with
Inform 7. That's a fact. Others keep saying you can use Inform 7 outside the
IDE but I don't see how that's practical. I'm just saying I wish Inform 7
was at least allowing people choices other than the canned way the IDE
works.
Warren
>
> The definition of "workable" here involves having Graham, Andrew, and
> David all sign off on the idea.
Cool. But how is that filtered back to the community to determine if it
would be a good change for more than just one person? Maybe someone else
would have a different addition to the idea or have an opinion of why a
certain things isn't a good way to go. Is community feedback solicited in
some way other than just individually?
Emily Short
No.
Most major changes to the system do result from feedback from a number
of people, but the design process in general does not involve an open
referendum. (There have been long flamewars already about whether it
should, so I am not really eager to re-debate this; it's not a decision
that falls to me in any case.)
Warren
>
>
> Most major changes to the system do result from feedback from a number
> of people, but the design process in general does not involve an open
> referendum. (There have been long flamewars already about whether it
> should, so I am not really eager to re-debate this; it's not a decision
> that falls to me in any case.)
>
No problem, I can understand your position. That's actually why I don't want
to submit change requests or ideas. If it's not open for some sort of review
then flame wars are more likely to start over design decisions. Thanks for
your input.
Warren
> (That's how you do user-focused design: consider what will most often be
> used -- and how -- and design accordingly. Or make the system
> customizable.)
If you see some of the other replies you'll probably have deduced that
Inform 7 is pretty much an exclusive shop. I don't think 'user-focused
design' is high on the list.
> All this said, (1) the IDE is relatively young; (2) perhaps you can
> suggest alternative approaches to the author; (3) the IDE itself is open
> source so if you know C++ you might be able to do something about this on
> your own. That said, your new version would be a fork of the build process
> since the development cycle for this (to my knowledge) isn't collaborative
> in a strict open source sense.
>
> - Jeff
>
You'll forgive me for thinking that each of your "solutions" are a bit
trite. Youngness of a development system is a good excuse only if it's clear
that the development path is inclusive, not exclusive. Alternative
approaches are not effective when they come from individuals who as a whole
aren't communicating as a group. I have no desire to modify the source for
the IDE.
Jim Aikin
> to create your extra source files as extensions. All of your source is
> stored in the Source tab, which corresponds to the story.ni file. You can
> use multiple files (non-extension based) outside the IDE, however.
This would be a total deal-breaker for me. I'm glad I found out about it, as
it confirms my decision to switch to TADS 3.
Having everything in one file is fine if you're doinking around, and it's
maybe manageable if you're writing a comp game that will end up as a z5. But
the source on the currently released version of Last Resort (in I6) is very
close to 925,000 bytes. I don't care how effective you are at organizing it
into chapters and sections -- that's just not a file you want to be working
in.
Plus, there's the question of revision history. Looking at my folder of
source files, I can see at a glance that today I worked on HouseInterior,
Tyrone, and Portables. That's useful information, even if its only utility
is psychological. And if I have two versions of HouseInterior, I can see
which one of them is newer or larger, which helps me keep track of my
workflow and prevent goofy mistakes. (Which I am very prone to, I might
add.) Putting it all in one source file -- no.
--JA
Jeff Nyman
>
> Plus, there's the question of revision history. Looking at my folder of
> source files, I can see at a glance that today I worked on HouseInterior,
> Tyrone, and Portables. That's useful information, even if its only utility
> is psychological. And if I have two versions of HouseInterior, I can see
> which one of them is newer or larger, which helps me keep track of my
> workflow and prevent goofy mistakes. (Which I am very prone to, I might
> add.) Putting it all in one source file -- no.
Yeah, I tend to agree, at least for my style of writing. Even when I'm
writing conventional fiction, instead of having an initial document that
contains everything, I tend to break things up. I break up my scenes into
different Word files and then even within that I might have sets of related
chapters as separate documents. Eventually I combine them all together, of
course, but having them apart really helps me keep things organized in my
mind and on paper. The same applies to me with interactive fiction.
Interestingly, if Inform 7's metaphor is akin to writing conventional
fiction (of the story story, novella, or novel) format, one of the methods
that's often touted of such writing is the idea of writing out scenes and
ideas on 3x5 cards. So I can easily see multiple source files fitting in
with the metaphor of planning out a book and writing a book and thus a
viable inclusion in the IDE.
(Actually, going with the plug-in idea I mentioned somewhere else, if Inform
7 had taken that route, I could imagine someone writing a version control
plug-in of sorts that would help the author keep track of version history.
Keeping with the metaphor, these could be called "Drafts" or something.)
- Jeff
Jeff Nyman
> If you see some of the other replies you'll probably have deduced that
> Inform 7 is pretty much an exclusive shop. I don't think 'user-focused
> design' is high on the list.
Well .... I'm not so sure I would say that. Like I said, I think the
metaphor is driving overall design decisions. I've seen feedback on this
newsgroup get incorporated into the IDE as it has developed, although those
have been relatively minimal changes in terms of overall design decisions.
It's the overall design I'm more "worried" about and what makes me hold off
on Inform 7 for now.
My feeling is that users of Inform 7 are sort of treated as incidental to
the "vision" that's being developed. Here my "incidental" has to be
understood as not meaning that there is no concern for the users; there
clearly is. Rather, it's just that the work on the IDE is going to go
forward to the extent that it matches the metaphor, without too much
questioning of whether the metaphor is good, or will hold up, or whether or
not it can be conceptually achieved in different ways. Clearly this is all
just my opinion.
> that the development path is inclusive, not exclusive. Alternative
> approaches are not effective when they come from individuals who as a
> whole aren't communicating as a group.
I tend to agree. Working in the quality assurance field as I do, I'm well
aware of how a requirements elicitation and gathering process (and then
subsequent design process) is best served when people with relevant opinions
actively collaborate and communicate ideas.
I've also seen where too many people collaborating and communicating can
effectively stall a project in its tracks. There's a balance here that has
to be achieved. Remember that it's not just the IDE being developed.
Underlying that is Inform 7 itself (the language) and its connections with
Inform 6 (another, related language). The IDE, while bound up with these
languages, is a separate element. So my point is that there's a lot of work
going on and, in some ways, the more important work is the language itself
since, without that, there's not much need for the IDE.
- Jeff
Emily Short
because I think I gave an incomplete impression of how the process
works.
Jeff Nyman wrote:
> "Warren" <.> wrote:
> > that the development path is inclusive, not exclusive. Alternative
> > approaches are not effective when they come from individuals who as a
> > whole aren't communicating as a group.
>
> I tend to agree. Working in the quality assurance field as I do, I'm well
> aware of how a requirements elicitation and gathering process (and then
> subsequent design process) is best served when people with relevant opinions
> actively collaborate and communicate ideas.
Yes, this *is* important.
For what it's worth, group discussion does happen informally both here
and on ifMUD: when people talk about the trouble they're having and the
changes they want to see, I pay attention. Such input affects which
features get added, which bugs get addressed most urgently, and how the
documentation evolves. And I try to keep track of things that are not
actually change requests: things that confuse people and things that
people are struggling to implement (in I7 especially, of course, but
also in other languages). Occasionally I have instigated discussion or
asked people to elaborate their thinking in these threads, but more
often changes are inspired by considerable discussion that happened
spontaneously.
When we add a new feature (such as the new disambiguation rules that
just went in), I review not only the bugs and suggestions database, but
also my notes and the contents of this newsgroup: I'm looking to see
that we're providing as much as possible of the functionality that
people have asked for and also trying to focus the documentation
examples on the tasks that people most want to do. Much of what I do on
this project is essentially user advocacy: I don't maintain any of the
code myself, so I don't have to worry about which things are going to
be hard to implement, and can afford to take the side of the demanding
author.
We still encourage people to submit particular feature requests
directly, for a bunch of reasons: because we want to make sure that
everything gets properly tracked; because occasionally I am out of town
or miss things or read the newsgroup when I'm somewhere where I can't
take notes; because some people tend to be less assertive than others
in group conversations and get drowned out even though they have
valuable ideas; and because writing up a feature request often gets
people to articulate their arguments more clearly and completely than
when they're posting a one-off remark on the newsgroup.
There are, of course, some things that have not happened even though
they are widely desired. Occasionally that's because they're impossible
to achieve or fundamentally inconsistent with the rest of the design,
but more often it's because the requested change relies on other
improvements first, or because the feature is a major undertaking and
there hasn't yet been time. We know, for instance, that it would be
good to provide other forms of documentation entirely: a more complete
guide to the syntax of the language, fuller indexing, and a secondary
document that would approach I7 less inductively and in a way more
directed at programmers. But these are all fairly massive things to
create, and in some areas the language is still subject to sufficient
change that we want that to stabilize first. These sorts of concerns
apply both to the language and to the IDE; with the IDE there's the
added issue that whatever we decide has to be portable to both
platforms.
It's true that there is a strong design impulse to keep the metaphors
consistent; when there's a conflict between a user's desire and the
metaphor, the result is usually that the specifics of a user's request
are denied but that we continue to talk about the motivating problems
behind the request and how to address them. Suggestions that *do*
happen to fit the metaphor are simply more likely to produce results
sooner, because the design problems have already essentially been
solved. This may still sound like it will lead to dogma beating
pragmatics some of the time; all I can say is that I think it mostly
doesn't. I also think the process of fitting new features into the rest
of the project in a consistent way tends to be a positive and
productive one. This is a different domain, obviously, but much of what
we've done with the language recently has been to try to make it *more*
consistent: to replace quirky syntax that exists only as a legacy from
Inform 6, to minimize the fiddly differences between kinds of rule, to
provide fuller indexing and documentation of various parts of the
system, to reduce the number of things that the Standard Rules are
allowed to do but the average user is not. There is still a lot to be
done along those lines, but I think what has happened so far makes the
language more accessible, more maintainable, and more powerful.
All that said: there is not, and almost certainly never will be, a
formal process whereby all design decisions get presented for communal
comment and approval before implementation. This is what I understood
the original poster to be asking about.
Ours isn't the only possible approach, and we certainly know it doesn't
please everyone. I sympathize to some extent with the ideology that
prompts the desire for a totally open process; I understand that some
people are driven off by the lack of one. I can also see the other side
of it -- I am a Mac user myself, not a Linux user, even though I
sometimes find Steve Jobs' vision silly or incompatible with mine, and
part of the reason is that I prefer the aesthetic effect. YMMV. Either
way, it's not my decision, the pros and cons have already been
articulated several times, and I don't plan to defend it. But I *am*
more than happy to pay attention to all forms of feedback on the
language and IDE, and willing (where I can) to clarify why we're doing
what we're doing. This is not a collaborative project in the sense that
the design process is open to all comers, but in a looser sense it very
much the product of collective effort; we rely on our users not only
for bug reports but also for more general discussion of usability and
guidance about future directions, and the communal conversations are an
important part of that.
Jeff Nyman
with what you say here. (In fact, this is why I was indicating that there
was more than just the IDE to be concerned with.) I also agree about not
necessarily having a "communal comment and approval", which is why I wanted
to make it clear that I've seen collaboration and communication stall a
project instead of helping it along. It's a balance.
Interestingly, the people that Inform 7 is most catering to right now (the
new or newer author) are probably those people who are not going to
articulate what many people who have worked with IF systems for years would
say. That can be a good thing and a bad thing. (Again, a balance.)
I think for some people who are looking for how the design process is done,
the problem is more the (apparent) intransparency of the entire process and
where Inform 7 can possibly go, based on the suggestions that are being
considered, those that are known to be out of the running, and those that
are just uncertain.
I think the tough part for Inform 7 is that the IDE is so bound up with the
language (at a certain level of approximation to most users) that all that
you talk about regarding the language changes and improvements are conflated
with IDE changes and improvements. That's also why I wanted to make it clear
to the original poster that I did see this as more than just the development
of the IDE. That is a concern for people, though (myself included): since
the only really effective way to utilize the language is via the IDE, IDE
concerns do take on an importance they might not have otherwise. (An example
might be how the TADS 3 language and/or library are not as locked into the
idea of the Workbench, per se.) That's probably why these topics about the
nature of Inform 7 focus on the IDE (whether people love it or hate it or
just fall somewhere in between).
- Jeff
jpl...@gmx.de
> Most major changes to the system do result from feedback from a number
> of people, but the design process in general does not involve an open
> referendum. (There have been long flamewars already about whether it
> should, so I am not really eager to re-debate this; it's not a decision
> that falls to me in any case.)
If I understand correctly, the current IDE is a shell built on top of
the Inform command-line tools. If the command-line tools were
documented and compilable, another IDE could be created. For example, a
truly cross-platform IDE on top of Eclipse, with an interface catering
to programmers. The web site mentions that the "source code [for the
command-line tools] is likely to be published in due course." Could you
please elaborate this point a bit?
-JPL
James Jolley
ems...@mindspring.com says...
I think for blind users like myself it would be good if we could gain
better access to some of the IDE. The major thing i've noticed in the
windows new version is that when a game is compiled, your not placed in
the area that says your game has been compiled into x rooms any Y things
and the index is updated. Instead, I have to hit f6 and the index comes
up. I wonder what was altered? Sometimes for me at least, it's handy to
know weather or not your code compiles and just to have that brief
snapshot of objects and rooms within it.
--
All the best
-James-
----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms at!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----
Emily Short
jpl...@gmx.de wrote:
> The web site mentions that the "source code [for the
> command-line tools] is likely to be published in due course." Could you
> please elaborate this point a bit?
As I understand it, the intention is still to publish the source, but
not until it has stabilized a little further and been more fully
commented. Graham is working on a systematic overhaul of different
parts of the ni source, to clarify the code and document it better;
this leads to some fairly considerable changes behind the scenes. For
instance, the most recent build fixes a lot of rules-related bugs and
introduces some new rule features as part of an extensive reworking of
the rules code. I suspect that we're still several builds away from
being done with that process, however.
Adam Thornton
Jim Aikin <rai...@musicwords.net> wrote:
>Having everything in one file is fine if you're doinking around, and it's
>maybe manageable if you're writing a comp game that will end up as a z5. But
>the source on the currently released version of Last Resort (in I6) is very
>close to 925,000 bytes. I don't care how effective you are at organizing it
>into chapters and sections -- that's just not a file you want to be working
>in.
I basically agree with Jim. The heading control in I7 is also next to
useless for me. The formatter often gets confused and decides that it
can't figure out my structure, but it's not actually a problem with the
source: when I do my release builds (which are with source) the source
HTML is always fine and is correctly broken down into the right
subheadings.
My current work is episodic. This means that I'm usually only working
in one fairly restricted portion of the file, except that as I need to
change the behavior of grammar or add footnotes and references, I have
to go to a completely separate part of the file, quite a long way away.
For the larger scenes, even paging back to the beginning of the scene
(where I keep, for example, my which-rooms-are-in-which-regions
statements and my Every turn while some-scene is happening: rules) is
slow and error-prone.
This could be ameliorated while maintaining a single monolithic source
file by a) getting the heading navigation mechanism to work reliably,
and b) allowing the author to collapse or expand headings within his
source: basically, an outline view, with the little rotating/expanding
triangles we all know and love.
Adam
Emily Short
> Interestingly, the people that Inform 7 is most catering to right now (the
> new or newer author) are probably those people who are not going to
> articulate what many people who have worked with IF systems for years would
> say. That can be a good thing and a bad thing. (Again, a balance.)
It could be, but (depending on what you mean by 'catering to') I think
your assertion is actually false: the majority of the bug reports and
feature requests are not from novices. There *are* a number of new and
mostly-new users, and its true that part of I7's design is meant to
appeal to them specifically; but new authors are more likely to submit
one or two comments apiece, rather than the more extensive feedback
that comes from users more certain of what they want, and we certainly
don't write off that input on the grounds that it doesn't come from our
target audience.
> I think for some people who are looking for how the design process is done,
> the problem is more the (apparent) intransparency of the entire process and
> where Inform 7 can possibly go, based on the suggestions that are being
> considered, those that are known to be out of the running, and those that
> are just uncertain.
Point taken. I'll draft a state-of-project paper and post it (I hope)
sometime during the coming week or so, by way of letting people know
what's still on the table, what's been nixed and why, and where we
think it's all going. I think both Graham and I are wary of doing this
-- wanting not to promise things we're not sure we can deliver, wanting
not to respond to proposals we haven't had a chance to look at
seriously, wanting not to spend more time explaining than we spend
implementing, etc. -- but I agree that it would be useful to
communicate better if we want people's informed input, and now would be
a good time to offer a general update.
In the meantime, here's the snapshot version of what we're doing now:
as I mentioned elsewhere in the thread, Graham is working on revising
major sections of the source code, which is necessary before the source
can be released. Our current process for each new build is to focus on
one area of the source, doing a bunch of related improvements, bug
fixes, and feature implementations, updating the documentation and
examples to match; and also to address any particularly urgent bugs,
any particularly easy bugs, and any small-to-medium documentation
problems. "Particularly urgent bug" means a bug that seems to be
causing problems for multiple reporters or newsgroup/ifmud users, or
one that affects some core functionality of the system. "Particularly
easy bug" usually means a bug producing an outright crash (and those
are good to eliminate wherever possible anyway); a bug requiring
trivial modifications to the standard rules; or a bug for which the
reporter has been able to suggest a patch. This approach partly
explains why builds have recently been arriving less frequently: our
previous approach was to focus mainly on fixing the top N bugs in the
bug list and then release a new build every few weeks, but this
involved less systematic progress and was not really the most efficient
way to address clusters of related bugs.
There are three areas we saw as needing reform particularly badly: the
handling of rules and rulebooks (addressed in the last build); the
handling of grammar (addressed in the build currently under
construction); and the handling of actions (to be addressed in a future
build). Just as the last build fixed a number of rule-related bugs and
introduced features made possible by that overhaul, the next build
addresses assorted bugs to do with the sorting of grammar lines and the
processing of parsing tokens; it also brings in a handful of new
related features. Behind the scenes, the source for that part of the
system has been simplified and the source documentation expanded.
I'm less involved in the part of the process that involves the IDE
development, and actual IDE *bugs* go through the respective authors
rather than coming to me; where we've identified features we definitely
want, things are added to the IDEs as David and Andrew are ready to add
them. But there are a number of larger-scale suggestions in the queue
that we need to go through systematically to approve or deny; they
haven't been addressed yet, but this does not mean that they are being
ignored for all time. It's largely that we seem to get more done if we
(mostly) focus on one thing at a time.
Andrew Plotkin
> In article <qTWlh.41539$wc5....@newssvr25.news.prodigy.net>,
> Jim Aikin <rai...@musicwords.net> wrote:
> >Having everything in one file is fine if you're doinking around, and it's
> >maybe manageable if you're writing a comp game that will end up as a z5. But
> >the source on the currently released version of Last Resort (in I6) is very
> >close to 925,000 bytes. I don't care how effective you are at organizing it
> >into chapters and sections -- that's just not a file you want to be working
> >in.
>
> I basically agree with Jim. The heading control in I7 is also next to
> useless for me.
It's useless to me, too, but for a shallow reason. I hate icons in my
toolbar, so I keep all my apps set to text toolbars. The header widget
does not work when textified. (I'm talking the Mac IDE here.)
(This particular prejudice causes me grief in more apps than Inform. A
lot of search toolbar widgets don't work when textified. I say this
only to make clear that most Mac users won't have this problem.)
> This could be ameliorated while maintaining a single monolithic source
> file by a) getting the heading navigation mechanism to work reliably,
> and b) allowing the author to collapse or expand headings within his
> source: basically, an outline view, with the little rotating/expanding
> triangles we all know and love.
I thought about this a little when reading the recent thread. I'm used
to developing I6 games in multiple files, using Emacs.
Now, what does that really mean? I have no *philosophical* objection
to working in one big file. What I have is a set of habits for working
on several different parts of a (logical) document at the same time.
(Of course sometimes I am only working on a single part of the file,
but in that case I don't care at all how big the file is.)
What do I do with my several Emacs buffers? Well, I switch between
them. This is a few keystrokes. (Ctrl-X ctrl-B, followed by about two
letters of the filename, TAB ENTER. If you're not an Emacs user, that
probably sounds insane, but never mind. The point is that it's fast
for me. The header widget is also fast, or at least that's its
intent.)
That's not all, though. I look for stuff in a buffer. This usually
means a text search, and the fact that it's a separate file is
relevant: I only want to search one part of the game. I don't want to
accidentally overshoot and fall into some other part -- that would
hurt me. (Again, this may not make sense if you're not used to a
dynamic wrapping search that leaps to stuff as you type it. But think
in terms of simply scrolling up and down a file with a scrollbar. You
want to be able to yank it around without fear of flying into another
file. If you have to constrain your own hand to a small region of the
scrollbar's vertical extent, it's not a very useful scanning habit.)
I also use the natural signposts of a file: the beginning and end.
Emacs (like the I7 IDEs) has quick shortcuts for "jump to start" and
"jump to end". So those are good positions for important stuff.
Finally, I rely on the fact that each buffer has its own cursor
position. If I am jumping back and forth between two buffers, I am
jumping back and forth between *specific points* in each buffer.
So to be totally useful to me, the expand-collapse triangles would
have to have something like all of these mechanisms. This is not a
trivial problem; it's not *just* a collapsing text display.
At the same time, I am not everybody; I'm not saying that the IDE
needs to have all this stuff *to be useful*. I do think it needs more
than a collapsing text display, but I don't know what the reasonable
point is.
(I think I would be satisfied with a collapsing text display
*combined* with multiple views of the same document. However, this is
probably more work than just adding the ability to edit multiple
files! And there are other options. E.g.: forget the triangles, and
have a multiple-view display where each view can be tied to a
subsection instead of the whole document.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Bush's biggest lie is his claim that it's okay to disagree with him. As soon as
you *actually* disagree with him, he sadly explains that you're undermining
America, that you're giving comfort to the enemy. That you need to be silent.
Jon Hendry
Andrew Plotkin wrote:
> I also use the natural signposts of a file: the beginning and end.
> Emacs (like the I7 IDEs) has quick shortcuts for "jump to start" and
> "jump to end". So those are good positions for important stuff.
>
Have you tried EMACS bindings in I7? If it uses the Cocoa text
widget, they will probably work. I note that ctrl-v works for page
down.
Also, option-escape brings up a word-completion menu.
vaporware
[...]
> What do I do with my several Emacs buffers? Well, I switch between
> That's not all, though. I look for stuff in a buffer. This usually
> means a text search, and the fact that it's a separate file is
> I also use the natural signposts of a file: the beginning and end. [...]
> Finally, I rely on the fact that each buffer has its own cursor
> position. If I am jumping back and forth between two buffers, I am
> jumping back and forth between *specific points* in each buffer.
>
> So to be totally useful to me, the expand-collapse triangles would
> have to have something like all of these mechanisms. This is not a
> trivial problem; it's not *just* a collapsing text display.
How about dividing the story file into virtual pages? Think of the
page-layout view in Word, but give each page its own cursor, and put a
row of tabs along one side to quickly jump between pages. Alter the
Find/Replace dialogs and the movement shortcut keys to work with single
pages or the entire document.
vw
Jeff Nyman
news:1167742737....@42g2000cwt.googlegroups.com...
> Andrew Plotkin wrote:
> [...]
> How about dividing the story file into virtual pages? Think of the
> page-layout view in Word, but give each page its own cursor, and put a
> row of tabs along one side to quickly jump between pages. Alter the
> Find/Replace dialogs and the movement shortcut keys to work with single
> pages or the entire document.
Yeah, this is somewhat along what I've been thinking about as well.
The Inform IDE already uses the concept of sub-tabs so the Source Tab could
potentially open up its own sub-tab list. The key difference here is that
the sub-tab number is not static. A user can create a new "file" (tab).
Further, since this list of tabs might grow larger than the width of the
panel, arrows for cycling the tabs become necessary. That might get into
accessibility issues.
There can be issues with this, however, as I've learned when using I7
outside the IDE. One is you have to combine the contents of the tabs into
one file. That's not too hard to do, of course, but it means there is some
consideration about what information is presented in what file. For example,
if the author writes some new kind definitions in a tab that is "after" a
tab where those kinds are referenced, the error logger would have to know
how to find the relevant area of the source.
The representation of the source would also have to be dealt with. Right now
if you play the game, the IDE saves your source. Depending on how these
multiple tabs (or, rather, the source in them) get represented in memory,
that might become an issue that has to be considered.
None of this, in my relative ignorance, seems insurmountable but does
probably require some thought regarding how implementation would proceed if
this was deemed to be a viable route.
- Jeff
Parham
Well. It's good as long as it's just pressing of a key. First time (as
I have said before), when I downloaded Inform7, JFW wouldn't read
what's written in the source section so I had to write it in Notepad or
somewhere else and then paste it in. And if it was not working, bang
bang! I had to just see what I could do. But now, fortunately, that is
fixed. And about Index, I'm not a pro-author; I'm not much experienced
either, but I just use the "search" in the game I'm already writing. It
might not be too long (already) but anyway, that just requires a little
work to work it out. The creater of this topic (who I forgot their
name) also pointed to a great thing. The mouse-keyboard combonation
should be decreased to keyboard-only IDE as much as possible. Because,
1) It would increase the writing speed;
2) It'd be good for the blind;
3) Some people are more easy-going with keyboard, and don't wnt to
switch to mouse, and then switch back to keyboard, and so forth (myself
included, even if I was not blind).
Or, we can have the current designed IDE as a scheme, and the new one
as the other, so that it'd be good for both kind of users. As Jef said,
a program should be usable by different kind of people, and if it is
not, it should be possible to re-design it (I don't know if it was a
correct wordd and way to say it, but anyway.). Re-designing means, I
don't want to click with mouse, so I put a hotkey for it --with my own
choice-- or the program can have hotkeys in one way, and in the other
scheme, be a combonation of both mouse and keyboard.
You might have a lot of things to say against what I've said here, but
keep in mind that I'm not as experienced as most people here are, so
what I say might require your ideas and etc.
Sorry for talking so much.
ChicagoDave
> This would be a total deal-breaker for me. I'm glad I found out about it, as
> it confirms my decision to switch to TADS 3.
I think this is where Graham's (et al) version of Inform 7 is missing
some portion of the IF author user base. But it's easily solved.
I'll get shot for saying this, but when Graham releases everything,
what's to stop someone from creating a sort of Inform 7 Pro version? So
someone adds a bunch of programmer type features, like source control,
collapsable views, multiple-file compilation. These things don't really
fit into Graham's vision and so probably should remain outside of the
standard version of Inform 7, but I think enough of the community might
appreciate a developer-focused version of the IDE when that becomes
possible.
Right now though, the thing is still in beta and to some degree,
product development. Not really a good time to focus on usability. I
think shoring up the underlying platform is a far more important task
and so Graham, Emily, Andrew, and David are doing the right thing.
I just hope they're open to alternative IDE implementations when the
source is released.
David C.
-
> What follows is personal opinion...
>
> This is one of the reasons why I've decided to abandon Inform 7 for now. For
> me, it's too problematic to use it without the IDE (rock) but I've found the
> IDE just constrains me too much (hard place). I still think the IDE has a
> lot of good ideas in terms of interface presentation, but I also think
> there's too much attempt to adhere to a metaphor. Having worked in interface
> design and usability testing for many years, too much reliance on metaphor
> makes me nervous about future development of a system unless the system has
> provisions to be altered or allows the metaphor to be somewhat fluid.
>
> A good example would be what you and Mike referred to. If it is, in fact,
> the case that most users will spend most time in the Contents and World
> sub-tabs of the Index tab, arguably those tabs should be closer together or
> provisions should be made for moving tabs in a way that suits the user.
> used -- and how -- and design accordingly. Or make the system customizable.)
>
> the extent that they allow you to write (code) in a way that matches how you
> think. (As just one example, Visual Studio 2005 allows you to choose between
> different interface styles based on the *type* of development you will be
> doing.) "Good" languages are like this as well, so so the theory goes: they
> are designed to match how people think about a problem domain. Inform 7
> appears to be trying to deal with both aspects. Time will tell how well it
> has done so.
>
> All this said, (1) the IDE is relatively young; (2) perhaps you can suggest
> alternative approaches to the author; (3) the IDE itself is open source so
> if you know C++ you might be able to do something about this on your own.
> That said, your new version would be a fork of the build process since the
> development cycle for this (to my knowledge) isn't collaborative in a strict
> open source sense.
>
> - Jeff
>
>
One of the issues w/ an IDE for Inform 7 is the language structure. A
few weeks ago, I'd looked at implementing a syntax-directed editor for
I7. As I got deeper into the requirements, I realized that the the I7
language is an outlier w/r/t/ most off-the-shelf code development tools.
The comments in the "Backus-Naur form for rules" example are
instructive for this thread.
Looking at the problem from the perspective of an historical IDE (even
the extraordinary EMACS) is probably a non-starter. We're going to have
to push ourselves to invent an IDE that does justice to the language.
This isn't to say that others haven't forged some trails:
"The Natural Programming Project is developing general
principles, methods, and programming language and environment
designs that will significantly reduce the amount of learning
and effort needed to write programs for people who are not
professional programmers."
Read more at http://www.cs.cmu.edu/~NatProg/
I enjoyed the christmas tree ornament. It was well rendered.
Jim Aikin
> what's to stop someone from creating a sort of Inform 7 Pro version?
In general, I feel it's preferable to have one person maintaining or at
least overseeing the whole thing. That's one of the points in favor of TADS,
actually: Mike Roberts maintains Workbench/Windows. One of the issues I have
with Inform is that, as far as I can see, Andrew is the force behind glulx,
not Graham. And then there are the various interpreter developers....
Sharing the workload is a good thing -- don't get me wrong. But too many
cooks can spoil the broth, that's all I'm saying.
> Right now though, the thing is still in beta and to some degree,
> product development. Not really a good time to focus on usability.
Oh, really? Seems to me that that's PRECISELY the time to focus on
usability.
--JA
Jeff Nyman
>
>> Right now though, the thing is still in beta and to some degree,
>> product development. Not really a good time to focus on usability.
>
> Oh, really? Seems to me that that's PRECISELY the time to focus on
> usability.
Yup, I tend to agree. Of course, by itself "focus" is a vague term, usually
implying a binary either/or. "Either we focus on this or we focus on that."
(The old Tyranny of the Or concept.) In reality, it usually makes sense to
have a multi-faceted focus on various aspects of the system under
development.
The question then becomes how much of the focus is placed on one aspect over
another.
One of the most common problems in software development is relegating
usability concerns or any sort of focus on usability for "later." (The
software industry is, finally, beginning to realize this and I've even seen
this trend in Web-based companies as well, which is refreshing.) In my
experience, the only time it generally makes sense to *not* focus on
usability early on in an SDLC is with a pure waterfall approach or when you
only have one person on the project and that one person has no experience in
interface design. With iterative development models, however, the opposite
is usually the case.
The problem is that "focus" implies a focused effort towards gathering
feedback and determining how to incorporate it from among a wide user base.
I think that part of Inform 7 development for the IDE is somewhat defocused
right now. It's clearly a personal opinion as to how effective or
ineffective that is for the development of the Inform 7 IDE and largely
debatable. On the other hand, I think the approach being taken with the
Inform 7 *language* is on the right track, in terms of being a bit more
limited and thus more focused.
- Jeff
James Jolley
parh...@gmail.com says...
-- Hi there,
I agree with many of the comments you posted. I haven't tried Inform 7
with JFW, only with Window-eyes. Window-eyes seems fine with it to a
point. The issue I have is with in some of the more enhanced functions,
like the scheme. I'd love to have access to that. The index is
relatively doable for us as blind users if you can manage using your
virtual cursor in JAWS for HTML pages.
It would be nice if there were hotkeys for each area of the I7 pages for
the index, scehem, etc.
What does Dave Kinda think of the suggestion?
d...@pobox.com
On Jan 2, 9:06 pm, James Jolley <james.joll...@btinternet.com> wrote:
> It would be nice if there were hotkeys for each area of the I7 pages for
> the index, scehem, etc.
On OS X (I don't do Windows) there is. Command-1 and Command-2 select
the left and right pages, and the function keys F1 to F8 select the
tabs/panels. Doesn't always seem to work, but that's the intention.
Maybe there is something similar for the Windows version.
drj
Jeff Nyman
news:1167815474.4...@42g2000cwt.googlegroups.com...
I think he might have been referring to a hotkey set for navigating within a
specific panel (i.e., a navigation hotkey for when you are on the Index and
another such hotkey when you are in the Skein).
In general, the relevant hotkeys for the Windows IDE:
Switch Window Panes: F6
Next Panel: SHIFT+F6
Next Sub-Panel: CTRL+F6
None of those would help you navigate *within* an actual panel, however. (If
that's what was meant.)
- Jeff
James Jolley
jeffnyman_nospam@nospam_gmail.com says...
It was what I meant. I am wondering if there could be hotkeys for
bringing up each of the tabs like index, scheme etc.
Jeff Nyman
news:MPG.2005e4ddc...@News-West.newsgroups.com...
>
> It was what I meant. I am wondering if there could be hotkeys for
> bringing up each of the tabs like index, scheme etc.
>
In this case, this might be something that would be good for a configuration
option; i.e., allowing the user to set hotkeys of their choice for each tab.
Figure that right now you have eight main tabs. Within the Errors tab, you
have two sub-tabs. Within the Index tab, you have seven sub-tabs. Any
arbitrary choice of hotkeys made by the developer is probably going to be
one of those things that is loved by some, hated by others.
As a sidenote: if you press F7 (on Windows, this is) you'll always be taken
back to the last sub-tab you were on in the Index tab. It's not the same as
having a hotkey but I've found that can be handy when I know I'm mainly
going to be referencing one of those sub-tabs. It's at least a quick way to
get back.
- Jeff
James Jolley
jeffnyman_nospam@nospam_gmail.com says...
How do I get to the part of the screen that tells you, after a
successful compile how many rooms and words were in the source? You know
how it did it in the previous version? That seems to be different and I
did like that function.
Jeff Nyman
> How do I get to the part of the screen that tells you, after a
> successful compile how many rooms and words were in the source? You know
> how it did it in the previous version? That seems to be different and I
> did like that function.
Well, let's say I compile a game. I'm automatically taken to the Game tab.
So, using only keyboard actions, I would have to do four clicks of SHIFT+F6
(to go to next tabs). That takes me to the Errors tab. That defaults to the
showing the Problems sub-tab. That will have text that says something like
this:
"The 39690-word source text has successfully been translated into a world
with 55 rooms and 117 things, and the index has been brought up to date."
If I hit CTRL+F6 that will take me to the Progress sub-tab but that just
contains the same information, for the most part. To my knowledge, there's
not an easier way to do that (solely with the keyboard) unless I'm missing
something terribly obvious.
Note that the Errors tab/Problems sub-tab shows you situations that are also
complete success (i.e., no errors or problems at all). That's a bit
counter-intuitive but I'm guessing people have gotten so used to that, they
don't question the names too much anymore.
Perhaps another suggestion for the IDE, then, is to have just a Compile
button that only takes you to the Problems sub-tab (even when there are no
actual problems, mind you) just to get the information about what was
acutally compiled. (Right now Refresh Index -- the F7 key -- acts sort of
like a compile-only option but, of course, it takes you immediately to the
Index.)
- Jeff
Parham
Well. The thing about the blind might be a bit out-of-topic but anyway,
for James' sake, there seems to be something wrong with what you've
gotten from what I said. I meant, it'd be good to add something like
"scheme"s. So we currently don't have anything called "scheme" or
something like that. And I'd work with jaws curser rather than pressing
shift+f6 over and over again. Aaaaargh.
I didn't know that sighted users also agree to have hotkeys as much as
I do. So I guess having a tab in the options to set hotkeys for
different tabs or things that you would need to access them quickly
would be great.
Victor Folk
> I didn't know that sighted users also agree to have hotkeys as much as
> I do. So I guess having a tab in the options to set hotkeys for
> different tabs or things that you would need to access them quickly
> would be great.
Hotkeys, yes please! I try to stay away from the mouse as much as
possible.
Cheers,
-- Victor
Will Shattuck
> I had intended not to get into this further, but I do want to clarify
> because I think I gave an incomplete impression of how the process
> works.
>
Hi Emily. Thanks for this well-written answer. I'm new to designing
IF, but have played it on and off since Zork. I just recently started
to pick TADS3 or I7 and I really appreciate the frank and honest answer.
I'll probably pick I7 due to the "non-programmer" way the language is
designed. I don't think well in the other way, but I7 seems to blend
with how I think.
Thanks again,
Will