I’m currently adding text selection support to QTads and I’m wondering if an IF interpreter should actually behave like a regular document viewer in this regard. A text adventure isn’t really a document.
The default behavior people expect when they see a bunch of text is that double-clicking on a word would select it. Does that make sense for IF? I personally like the way Hugo handles double-clicks: a double-click doesn’t select anything, but instead copies the word to the player input field.
I’m inclined to do the same in QTads, but if people find that behavior strange, I’ll probably just make it an optional setting instead.
I can’t see any harming in adding it as a default feature. It seems unlikely anyone would do it by accident (or find it annoying if they did), and it can be really helpful for lengthy nouns. iFrotz also uses the Hugo approach.
98% of a text adventure is a text document – albeit one which is repeatedly skimmed through after (at most) one careful reading.
The business of pasting in a double-clicked word is, I’d say, an established convention in mobile IF UI. I’m not as convinced for a desktop UI. Reasons: one, the selection conventions for desktop documents are better established. (Not quite the same between Linux/Win/Mac, but within an OS, established.) Two, typing is easier on desktop to begin with, so there’s less need for the shortcut. Three, the copy/paste shortcuts are also easy and well-established. If I want to copy down a word on a Mac interpreter, I’ll double-click and then hit cmd-C cmd-V. That’s hardwired.
(But please autodirect the paste to the input line! Don’t make me mouse-click down to the prompt before I paste. That’s something that all IF UIs should definitely get right.)
I think this is trickier than it seems when you consider future tablets running Linux. This is a great platform for QTads and I think you want to keep future users of those devices in mind. If you’re thinking about convention then selecting on double-click wins, but for usability I’d have to say copying to the input line.
So of course the answer is, make it configurable …
Seriously though, I’ve always liked how iFrotz does it so I voted for that.
Heh, I was hoping for something unanimous. Zarf makes a good point though; if double clicking wouldn’t select the current word, the program would feel like the odd man out compared to other apps. So selecting the word instead of pasting it is most probably the reasonable default behavior.
Instead of having to switch the behavior through an option, I thought about having a modifier for it. For example, holding down Shift (or maybe Control?) while double-clicking would paste the word. (This is probably only important for Mac and Windows though, since on Linux there’s a second clipboard where you can paste by middle-click whatever is currently selected without having to manually copy it first.) The configuration option would then flip the behavior. With the option disabled (the default), double-click selects, modifier + double-click pastes. With the option enabled, double-click pastes, modifier + double-click selects.
Does that sound reasonable?
I fully agree here. If there’s only one place where a paste could possibly end up, there’s no need to explicitly point that place out by selecting it first.
…