twinejs
twinejs copied to clipboard
klembot
2.4.x Allow passage windows/dialogs to be moved & resized
Is your feature request related to a problem? Please describe.
The 2.4 editor allows multiple dialogs (find/replace, story info, passage editors) to be open at once, stacking them up along the right-hand side of the story window. While this is a significant improvement on the 2.3 idiom, it has led to a number of responses highlighting problems with the interface:
- Users have reported the editor windows being too narrow (c.f requests for "expanding editor")
- Users have reported lack of vertical space with multiple editors open (e.g. https://github.com/klembot/twinejs/issues/1177)
- Users have requested to have the editors on the left of the screen instead of the right (https://intfiction.org/t/twine-2-4-0/56720/9)
Describe the solution you'd like.
One solution that might answer all of these issues is to allow the user to move (by dragging titles) and resize (by dragging sides/corners) all of the editor windows. They can then arrange them as they like — for example placing two passage editors side by side while working on them.
Describe alternatives you've considered.
It's possible that the issues mentioned above could be tackled individually by separate tweaks, e.g.
- Allowing editors to have a single narrow/wide toggle as in 2.3
- Allowing the user to pick left or right for dialog position
- Allowing editor collapsing in passage dialogs only
However, implementing window move/resize has the potential to answer all of these issues at once (although it might not obviate the need for toolbar collapse and left/right preferences), as well as others not yet listed that would otherwise require their own individual tweaks.
Additional context on this suggestion.
This is a very standard idiom, essentially transforming the dialog layer into a window manager. (Would you allow overlapping windows — unclear). It would also require the editor to track window state, although it already does this for collapsed/expanded and dialog stacking order.
I'm not sure how long I'd expect the window position to be remembered — existing applications and OS's vary widely in how long a custom window size/position are saved. It might be enough to remember the positions only as long as the story is open, for example.
Presubmission checklist
- [ ] I am interested in working on code that would implement this feature request. (This is not required to submit a suggestion.)
- [X] I have done a search and believe that an issue does not already exist for this idea in the GitHub repository.
- [X] I have read and agree to abide by this project's Code of Conduct.
I'm not ready to take on the complexity of a full-fledged window management system right now. The idea, kind of, is right now more similar to the stacked palettes of Figma or Photoshop, though this is kind of visually confusing because they don't look like them. I didn't want the screen space to be gobbled up if you didn't have any dialogs open.
So for now, I'd like to try to make the current approach better.
I can understand that, though I think you are going to keep getting requests for this. it was never an issue before because 2.3 and below enforced that "single passage in the middle and like it" approach. Now you've opened up the possibilities, but still left unusual constraints.
I can back Hituro up. Writing on the side is a bit awkward to do. I would be ok with forcing the window in the middle of the screen even, as a quick, easy method. Resizing and custom positioning is ideal, and definitely should be a goal for the future, but at least putting the window in the middle like how it was in 2.3 would be a huge upgrade.
Besides that though, 2.4 looks and works fantastically, great update.
Resizing and custom positioning is ideal, and definitely should be a goal for the future, but at least putting the window in the middle like how it was in 2.3 would be a huge upgrade.
I don't follow this part. A goal of 2.4 was to allow people to look around the story map, edit other passages, and generally make changes while a passage is open for editing. It seems like to me that putting the dialogs right in the middle of the screen would be very distracting and get in the way? (Are you arguing for going back to the modal editor?)
No, I want to stress the new version is very good. Being able to look over the map while a passage is open, or opening multiple passages, is incredibly useful when you're doing work that takes place on multiple passages.
However, when I'm writing the story itself, and focused on one specific passage, having it in the middle with the rest of the story blacked out was useful. It let me focus entirely on the passage, in a way that is comfortable.
So for me, it's a difference in the work I'm doing. When doing things like CSS, or coding, the new version is better. But when I'm focusing on writing the story, the older is ideal.
I really do want to stress that the new version is great, and the work you're putting in is amazing. Maybe having a button on the passage, that would put the passage in the middle, and darken the background, like in the previous version. That way you can switch between multiple passage editor, and a more narrative focused version.
I get it now, thanks— that explanation does make a lot of sense. Something I’ve been thinking about is adding a maximize button similar to what was in the old editor, similar to what you’re suggesting.
This issue probably makes https://github.com/klembot/twinejs/issues/1040 redundant
Hi everyone, I just got started with Twine today and am liking it so far! The amount of screen space (or lack thereof) that an open passage gets can be a bit frustrating, though. Being able to maximize the passage editor would make it more comfortable to use.
Yes a maximize button is essential especially when having to deal with a lot of complex code in a passage. The side stack is a nice feature to check code between passages, but when editing the code having a full screen / focus mode will really help. Otherwise it's having to cut and paste passage code into another editor to get a better view of the code and then putting it back.
