Adds: document menu (copy, paste, delete, duplicate, split, merge, etc.)

[olivierkes]

(from #200 (comment))

Another thought is the ability to cut a scene at a selected point and create a new scene containing the text below that point. One of the few functions I do miss from Scrivener. It made the importing of a single file containing everything quite manageable.

I just added this function to manuskript. It's in the develop branch.

In the new Documents menu:

• Split at cursor (CTRL+K) will split the current text at cursor. If there is a selection, it will be used for the title of the newly created item.

• Split… (CTRL+SHIFT+K) will open a dialog, in which you can chose a "split" mark. The text will be splitted at every occurences. If you call that while having selected multiple items, it will be applied to all. If you call that on a folder, it will be applied to every children.

Edit: dialog should read "escape sequences". Corrected.

[gedakc]

I have a discussion thought.

Normally the menu entries like "Copy, Cut, Paste, ...." are placed under the Edit menu heading. For an example of this take a look at an application like Firefox.

Perhaps we should be placing these menu entries under Edit as well, and get rid of the Documents menu?

Please note that I am not a GUI expert.

EDIT I'm not sure what to do with the Documents entries "Move up, Move down, Merge, Split, Split at cursor".

EDIT 2 These remaining Documents entries appear to be commands to change the structure of the document. Perhaps Structure would be a better menu heading???

EDIT 3 Found an issue. When starting manuskript with no document yet opened, the Documents menu entry is active. Only File should be active at this point in time.

EDIT 4 'Just found another anomaly. After a project has been loaded the Documents menu is visible only when Editor has been selected on the left-hand-side. The Documents menu magically disappears if other left-hand-side selections are made.

EDIT 5 Found another mismatch. The Documents menu has Delete shortcut key Del and Duplicate shortcut key Ctrl-D. However if I right click on a text in the Project tree, Delete has shortcut letter D and there is no Duplicate entry. I think we should be cautious here. Many editors like Emacs use Ctrl-D for delete, not duplicate.

[olivierkes]

Good points!

My thought for naming that menu Documents: that's what Scrivener do. hum. It makes sense for me in the sense that this menu is really about "items" in themeselves, not the usual "edit" like copy/pasting in the text of an item. But Structure works, I like it.

EDIT 3 Found an issue. When starting manuskript with no document yet opened, the Documents menu entry is active. Only File should be active at this point in time.

That's a bug, will fix.

EDIT 4 'Just found another anomaly. After a project has been loaded the Documents menu is visible only when Editor has been selected on the left-hand-side. The Documents menu magically disappears if other left-hand-side selections are made.

This is because as of now, this menu is only useful in the Editor. Maybe it could be used also for other stuff, but for now it's only for outlineItems. Making it disappear seemed to make it simpler. But I could disable it. Would that be better?

EDIT 5 Found another mismatch. The Documents menu has Delete shortcut key Del and Duplicate shortcut key Ctrl-D. However if I right click on a text in the Project tree, Delete has shortcut letter D and there is no Duplicate entry. I think we should be cautious here. Many editors like Emacs use Ctrl-D for delete, not duplicate.

1. Yes, we should normalize between menu and context menu.
2. I think CTRL+D is most often used for duplicates in many apps. Do you any of other editors that use CTRL+D for delete?

[gedakc]

@olivierkes: My thought for naming that menu Documents: that's what Scrivener do. hum. It makes sense for me in the sense that this menu is really about "items" in themeselves, not the usual "edit" like copy/pasting in the text of an item. But Structure works, I like it.

Again I'm no expert on this. I can go either way. If Scrivener uses Documents and you like it then please feel free to leave it that way

@gedakc EDIT 4 'Just found another anomaly. After a project has been loaded the Documents menu is visible only when Editor has been selected on the left-hand-side. The Documents menu magically disappears if other left-hand-side selections are made.

@olivierkes This is because as of now, this menu is only useful in the Editor. Maybe it could be used also for other stuff, but for now it's only for outlineItems. Making it disappear seemed to make it simpler. But I could disable it. Would that be better?

I just searched on this topic and came up with StackExhange: Don't hide or disable menu items?. This was the way the GUI has handled on the Palm Pilot in PalmOS. One person had a good argument for seeing at a glance a long list of disabled items as opposed to clicking on each one to see it is disabled.

Currently we have other menu items disabled (for example before opening a document), so it might be easiest at this point to simply disable the menu item when it cannon be used.

@gedakc EDIT 5 Found another mismatch. The Documents menu has Delete shortcut key Del and Duplicate shortcut key Ctrl-D. However if I right click on a text in the Project tree, Delete has shortcut letter D and there is no Duplicate entry. I think we should be cautious here. Many editors like Emacs use Ctrl-D for delete, not duplicate.

1. Yes, we should normalize between menu and context menu.
2. I think CTRL+D is most often used for duplicates in many apps. Do you any of other editors that use CTRL+D for delete?

You're right. I could only find editors like Emacs, or ones like Bash that can simulate emacs style editing. So I was wrong to say many editors.

Because the Project tree pane also has buttons for adding and deleting folders and texts, we might consider adding more icons there. It's just a thought. Icons can clutter the User Interface too, so I think it best to only have commonly used icons displayed.

[olivierkes]

Lasts commits:

• Disable Documents menu instead of hiding it
• Disable Documents menu when there is no project
• Add Duplicate in context menu (and fix a bug: duplicate would change clipboard content)

I kept the name Documents for now, we'll see if we find something better…

I did not see the "Del" keyboard shortcut in context menu..?

[gedakc]

Thank you for all the updates you've been making.

I did not see the "Del" keyboard shortcut in context menu..?

For Delete I think we wish to be as consistent as possible. The discrepancy I see now is:

• Documents -> Delete uses the letter e as the shortcut in the menu
• Project tree: Right-click -> Delete uses the letter D as the shortcut in the menu.

Note that there are differences between what is available in the Documents menu versus what is available in the Project tree: Right-click menu. For example Duplicate is missing from the right-click menu. If these two menus do the same thing, then I think it might be less confusing to users if both include the same options.

EDIT Oops, missed one your commits. The newly added Duplicate uses a different letter again: a. I think we should be consistent with these menus. It is also grouped differently in a different section of the menu.

[olivierkes]

Strange, here I don't have letters:

[olivierkes]

Added those shortcuts, and tried to harmonize a bit those menu.

Strange, there were no

Window menu:

Context menu:

[gedakc]

Thanks for providing the menu screen shots. I now see the same as the screen shots indicate. :-)

In my opinion "Cut, Copy, Paste, Delete" still belongs under the Edit menu, and not the Documents menu. Placing these under Edit is more consistent with other applications, such as Firefox.

Also if we add more functionality like copy and paste for characters, plots, or worlds, it would be best to have these menu items in the same consistent place. Most applications seem to place "Cut, Copy, Paste, Delete" under the Edit menu.

[olivierkes]

Only cut copy paste delete? What about rename? Duplicate?

Or the whole menu?

I don't see a coherent rationale yet for what exactly each menu should be.

[gedakc]

I don't see a coherent rationale yet for what exactly each menu should be.

You are absolutely correct. This documents menu really has me puzzled. There is something about it that just doesn't seem to fit (at least in my mind).

'Just last night I was thinking about the Duplicate functionality, which is very useful.
I thought to myself I wonder why other editors do not have Duplicate?

Then it came to me. Other editors already do. It's called Copy and Paste. (palm striking face icon)

With this in mind, can you think of a reason why we need a Duplicate?
Or is Copy and Paste sufficient to make a copy or duplicate of a text, etc.?

[gedakc]

I would like to help make this enhancement fit as best as it can from a GUI perspective. I like the new Rename, Move Up, Move down, Merge, Split, and Split at Cursor functionality. If we can get this into the GUI mostly correct the first time, then we will avoid confusing our users later by moving functionality from one menu to another.

I guess I got caught off guard when we decided to make a 0.6.0 release from the develop branch. I admit that I did not look at this before in the develop branch so my bad. I should have more thoroughly reviewed this before we pulled it into master for the release.

EDIT On another project I work on, one person may write an enhancement, but another reviews it. If it looks good to both, then the change is committed to master. These approved commits build up in the master branch until it is decided to make a release. At that point an upcoming release announcement is made (for in 1 weeks time), and no further changes are made to master. During this 1 week period translators update the language translations, and the master branch undergoes testing to ensure proper operation. Then on release day the code is tagged and released.

Perhaps something like the above might work for manuskript?

EDIT 2 I think the above proposal is similar to the way github suggests working in the document Understanding the GitHub Flow.

[gedakc]

I've been looking at other applications to see what they do for GUI menus. Following is a screen shot from the Dolphin file manager which is part of KDE.

In the above screen shot a list of valid options is shown only when a user right-clicks. There is no Edit menu or File Manager menu.

Perhaps to keep things simpler for now, we might consider not adding a Documents menu?

The manuskript right-click menu might then look something like the following:

• Open ZZZZZ
• Open ZZZZZ in a new tab
• ===
• Expand All
• Collapse all
• ===
• New Folder
• New Text
• ===
• Cut
• Copy
• Paste
• ===
• Rename
• Delete
• ===
• Move Up
• Move Down
• ===
• Merge
• Split ...
• Split at cursor
• ===
• Set POV
• Set Status
• Set Label
• ===
• Set Custom Icon

EDIT This is just a proposal. If there are situations I have not thought of then please let me know or suggest changes.

[olivierkes]

On workflow

I'm more or less following the git flow model. If we wanted to follow it strictly, then we should have created a release branch (instead of merging to master). On the release branch, no new feature is added, bugs are corrected, translators do their job. And when the release is ready, it is merged in master and back in develop.

This allows for every commit on master to be a workable release, and development can continue (with new features added) on the develop branch.

Would you be okay with that?

I guess I got caught off guard when we decided to make a 0.6.0 release from the develop branch. I admit that I did not look at this before in the develop branch so my bad. I should have more thoroughly reviewed this before we pulled it into master for the release.

With the actual scale of manuskript it's not such an issue. We can keep code on master before we make an official release and publish packages.

On menu

We cannot simply imitate firefox, in that it's an entirely different type of software. I took a look at other outliners:

• omnioutliner menu
• scrivener

From that, I take:

• Edit menu: copy, cut, paste, delete, etc.
• Organize (omni) / Documents (scriv): Add, remove, move, split, etc.

I think this comes back to what you said :)

About duplicate

Both omni and scrivener have a Duplicate entry menu. Yes it's almost like copy/paste, and yet it might be convenient. Omnioutliner put's it in Edit, Scrivener in Documents.

I think it makes more sense in Edit (since it is similar to copy and paste).

Menu

So we would have something like;

• File: things about the whole project
• Edit: things concerning the current item (though copy can copy more than one item)
• Organize/Structure/Documents/Outline: things that will change the outline (move) and concern either no items (add), or multiple (split, merge, …)

[gedakc]

Thank you @olivierkes for your response and links to other reference material.

On workflow

@olivierkes: I'm more or less following the git flow model. ... Would you be okay with that?

I will work with whichever method you prefer. Without your work, there would be no manuskript.

I am extremely happy that you released manuskript as Free Libre Open Source Software.

I do not wish to stiffle your creativity in any way.

Now that I've read up on the git flow model, I have discovered that some issues I encountered are because we didn't follow the git flow model properly. For example it says that all feature branches must be merged back into develop. We have not strictly followed this (for example commit 429e0a1 - Update README.md for 0.5.0 release was only committed to master and not develop.) This has led to a develop branch that does not include all of the commits in master. (A quick look will show a different screen shot on the code page for each branch.)

Personally I prefer using the simplest approach when possible. I think that the github flow is simpler to maintain, as explained in the article GitHub Flow by Scott Chacon.

To sum up, I will work with whichever method you prefer.

On menu

Thank you for the links to these other outliners. I particularly like the name Organize from the omni project. It describes what the menu options Add, Move, split, etc. do.

About duplicate

Indeed both of these other outliners do have a Duplicate entry menu.

Is there some key functionality that Duplicate does that is not included in Copy and Paste?

If these are essentially the same, then I think only Copy and Paste is needed. It also makes the menu shorter by one item.

Menu

Your summary of the top level menu items makes sense to me. My vote would be for the name Organize instead of Documents.

[olivierkes]

Workflow

When I first started to use git, I did a quick search and found the article about git flow, and thought it was like a standard. Now I've read the post you linked, and few others, and discovered a world of religious-like convictions about achieving perfection in using git :)

Thanks for bringing that to my attention. Probably git flow is a bit to much for a project of our scale. But since I'm getting use to that I'd like to keep it for now, and try to use it a bit more properly. And I keep in mind the idea of a simpler workflow like github's.

So it means that for now we keep both master and develop, and for the next release, when we feel develop is almost ready, we create a feature branch to work on finalization (last bug fixes, translation, readme, changelog, etc.).

Menu

Sorry I saw your post from yesterday with the dolphin's screenshot only after writing mine. I want to keep the idea of a window menu, and not just only a context menu. (Also because it is easier that way to have keyboard shortcuts, though I'm sure I could find a workaround).

I like Organize.

Duplicate is almost like copy/paste, the only difference is that the clipboard's content is not changed. So you can for example: cut some text, duplicate item, and paste text. Or copy item A, duplicate B, and paste A. That's not critical, so I'm okay with removing it.

Summary

• Move copy/cut/paste/delete/rename to Edit menu (delete also?)
• Change Documents to Organize
• Remove Duplicate

[gedakc]

I'd like to keep it for now.

Okay, that works for me. We'll stay with git flow for now. We should probably fix the develop branch so that it includes the commits that were made to master only.

Move copy/cut/paste/delete/rename to Edit menu (delete also?)

Yes, I think delete should also be moved to the Edit menu. Also from looking at other applications there appears to be a pseudo-order of these menu items. The order I observed is:

• Cut Ctrl+X
• Copy Ctrl+C
• Paste Ctrl+V
• Delete Del

Regarding Duplicate please feel free to include it or remove it as you see fit. I only wished to state my opinion (I like to keep things simpler, menus shorter, etc).

[olivierkes]

We should probably fix the develop branch so that it includes the commits that were made to master only.

Yes, I'll merge master into develop once we're done with those fixes.

Also from looking at other applications there appears to be a pseudo-order of these menu items. The order I observed is:

Thanks, will follow that!

[olivierkes]

What do you think @gedakc?
Is master ready for 0.6.0?

[gedakc]

Thanks for working on this issue. I'll re-test the master branch soon.

In the meantime I noticed there is a new "i18n/manuskript_fr.qm" file checked into the repository -- commit b942342. I am curious. What is this new file?

Thanks,
Curtis

[gedakc]

Overall my testing of the master branch has gone well. The new features you added are working splendidly.

In my testing I came across three minor issues. None of these would be cause to hold up the release if case you wanted to get the release out.

• Items in the Edit menu are disabled when left-had-side Navigation items other than Editor are selected, even if a user has some text highlighted. Note that the user can still use the shortcut keys to cut/copy/paste/delete text. Again this is very minor and probably not worth worrying about at this time.
• The order of "Cut/Copy/Paste/Delete/Rename" should probably be changed in the Project tree - right-click menu to match that in the Edit menu.
  UPDATE: Another option is to remove these entries from the right-click menu because they are available via the Edit menu and via shortcut keys.
• The Duplicate entry is still shown in the Project tree - right-click menu.
  Did you choose to keep this menu item?

[olivierkes]

Thans for testing @gedakc!

In the meantime I noticed there is a new "i18n/manuskript_fr.qm" file checked into the repository -- commit b942342. I am curious. What is this new file?

This is the binary file containting the translation. Qt does not us the .ts file, but compiles it into that .qm file. Other Qt project do not keep those in the git repository (only the .ts files), but I felt it makes it easyer for people to clone & run. Otherwise it would add a dependency (pyqt-tools or something like that), and a step.

• Items in the Edit menu are disabled when left-had-side Navigation items other than Editor are selected, even if a user has some text highlighted. Note that the user can still use the shortcut keys to cut/copy/paste/delete text. Again this is very minor and probably not worth worrying about at this time.

OK we'll leave it at that for now.

• The order of "Cut/Copy/Paste/Delete/Rename" should probably be changed in the Project tree - right-click menu to match that in the Edit menu.
  UPDATE: Another option is to remove these entries from the right-click menu because they are available via the Edit menu and via shortcut keys.

I will change the order

• The Duplicate entry is still shown in the Project tree - right-click menu.
  Did you choose to keep this menu item?

No, forgot to remove it there to. Will do it.

I noticed another issue in Project tree - right-click menu: when right-clicking on an item that is not the current item, the selection does not change, and some of the menu items apply to selected item while other apply to item under mouse. Secifically, "open/open in new tab" and "expand/collapse" will apply to item-under-mouse, and all the others (copy, paste, change status, change icon, etc.) will apply to selected item.

What should be the behavior here? At least, I think, every entry in context menu should apply to the same item. So:

1. when right-clicking on another item, select first that item (but then it's not possible to be editing "scene 1", and to "open scene 2 in a new tab".)

2. Apply all effect to item-under-mouse, maybe saying for each "copy {item name}", "rename {item name}" as is the case for "open / open in new tab".

Do you have an opinion?

[gedakc]

some of the menu items apply to selected item while other apply to item under mouse.

Good work discovering this issue.

What should be the behavior here? At least, I think, every entry in context menu should apply to the same item.

I agree. Consistency is very important in the user interface.

Do you have an opinion?

Thank you for asking.

To learn more about how another application deals with this issue I tried using the Dolphin file manager from KDE. The way it works is as follows:

• If no selection is highlighted and the user right-clicks on an item then Dolphin selects the item under the mouse and brings up a menu of options for that item.
• If a selection is already highlighted and the user right-clicks on one of the items within the highlighted item(s) then Dolphin brings up a menu of options for the item(s).
• If a selection is already highlighted and the user right-clicks on an item not within the highlighted item(s) then Dolphin cancels the previous selection and selects the item under the mouse and brings up a menu of options for that item.

If we were to follow this Dolphin behaviour then the concept of having a different area selected than the one under the mouse when right-clicking does not exist. This would mean:

1. when right-clicking on another item, select first that item (but then it's not possible to be editing "scene 1", and to "open scene 2 in a new tab".)

The user could perform a similar action in two steps by right-clicking to "open scene 1 in a new tab" and the left-click to select "scene 2".

Additionally the user would still be able to expand or collapse a folder without selecting it by left-clicking on the triangle beside the folder in the Project tree.

I think it is better to implement option 1 because this aligns with at least one other application's behaviour.

Some More Issues

• If a user copies a scene, they can paste directly after the scene using Edit -> Paste. However if they right-click on the scene for a menu, then Paste is disabled. I think we need to be consistent with how we handle paste. I think it is okay to paste after the scene as implemented in Edit -> Paste.

• There is a horizontal line dividing the Paste and Delete menu items in the Project tree right-click menu. I think we should remove this horizontal line to be consistent with the Edit menu.

[olivierkes]

You are so helpful, thanks!

• I followed you advice and chose option 1
• Paste is never disabled
• The divider has been removed
• And I found a way to speed up that menu generation by caching some part of the menu

[gedakc]

These new updates work wonderfully!

If you are in agreement then I think we are ready to tag and release 0.6.0.

As before I offer to create the Windows PyInstaller package, and also the Debian based Linux .deb package and Fedora based .rpm package. I can also work on the news announcement and update the download page if you like.

[olivierkes]

Good. I tagged and released.

Yes please if you can create Windows package and .rpm package. The .deb package is created automatically¹, I already uploaded it to the release. But maybe you can test if it works properly.

And I'm glad if you work on the announcements and download page! Thanks!

¹: As a reminder

• On master, every commit creates a package in www.theologeek.ch/manuskript/releases/manuskript-{version}.deb (where {version} is the value in manuskript/version.py). And every tagged commits creates an OSX package directly uploaded to the release on github.

• On develop, every commit creates a deb package in www.theologeek.ch/manuskript/releases/manuskript-develop.deb and a PyInstaller OSX package in www.theologeek.ch/manuskript/releases/manuskript-osx-develop.zip

• I had tried to create a script for .rpm but had some issues (can't remember what exactly)

[gedakc]

Thanks for setting up automatic creation of the .deb package. I just tested it on Debian 8 Jessie and it worked well.

I'll start work on the .rpm and Windows PyInstaller packages, then follow up with updating the Download page and make a release announcement.

[gedakc]

I had tried to create a script for .rpm but had some issues (can't remember what exactly)

Was the rpm build error message related to the new .travis.yml file?
I had to delete this file for process to succeed. I updated the instructions to Package Manuskript for Linux with rpm.

I have completed the following for the 0.6.0 release:

• Test .deb package for Debian based distros
• Create and test .rpm package for Fedora based distros
• Create and test Windows PyInstaller zip package
• Update Download page for 0.6.0 packages
• Announce Manuskript 0.6.0

@olivierkes would you be able to update the CHANGELOG.md file?

I am happy to have a new, more stable release out. :-)
Thanks to everyone who helped to make manuskript what it is today!

[olivierkes]

Thank you so much @gedakc! Good work!

I'll have to look for the changelog, because it is automatically created based on github closed issues, but my settings use dates and not milestones, so issues that are closed for 0.7.0 are included in 0.6.0 (because they were closed before the tag was added). I'll need to take a closer look... but tomorrow! (it's getting late here).

I'm really happy to see manuskript being more and more used. And I'm looking forward tomorrow: potential reports of NaNoWriMo successes using manuskript!

[gedakc]

Today I saw another good manuskript review on AlternativeTo.net.

I'll close this issue so that it can be included when you are able to generate the CHANGELOG.md.