We use dynalist in regular basis, while we encountered some bugs. As I didnât find any dynalist bug tracking system anywhere, creating separate topics for each bugs would take significant amount of time and bug tracking for developer would be messy so I decided to post collection of bugs in just one topic. Also I have included workaround with issues and as well as suggestion too within the bug.
Bugs
-
When moving the text insert mark up with arrow keys, starting in the first position in the second line of an itemâs note, the first line above jumps over.
-
The position of the âUndoâ icon in the mobile version changes after the first undo to make space for the âRedoâ icon that then appears, making it uncomfortable to use âUndoâ multiple times in a row.
The following code fixes this:.MobileHeader-option--undo { right: 175px; }
-
When using âCtrl + arrow upâ and âCtrl + arrow downâ to move items and the text cursor is located in the note section of an item, then the viewport will jump to the top of the document in addition to moving the item.
Reproducible in ca. 95% of cases. Observed on: Version 64.0.3282.119 (Official Build) Built on Ubuntu , running on Ubuntu 17.10 (64-bit) -
When moving the text insert mark down with arrow keys, starting in the last position in the second to-last line of an item, the last line below jumps over.
Refers to an item, not to the note of an item. So, we need to create multiple lines in it using âCtrl + Shift + Enterâ. -
After cut & paste of a task, its link changes.
Does not happen after moving it with Ctrl+arrows, or with âcontext menu â Move to âŚâ. -
Scrolling with the mouse wheel or touchpad is only possible at the beginning of a drag&drop operation with an item.
Means, immediately after the click-and-hold on the item, before moving the mouse pointer for a pixel after that.
It would be very useful however to be able to scroll during a drag & drop at all times, as two-finger-scrolling is much more comfortable and precise than moving the item to the edge of the viewport and waiting for the document to scroll.
The breadcrumb items at the top of the main content area should be viable drop targets during drag&drop of list items.
It should be possible to drag&drop into closed items.
Namely, by dropping on the item. A gray background behind the itemâs text would indicate this case, in contrast to the gray line above or below the item when dropping between two items (like now). -
When trying to create a line break at the end of an item by pressing âCtrl + Shift + Enterâ, it will not work the first time.
It will work the second time and afterwards though. And this is permanent: even after reloading Dynalist, it will work in the items where it has been tried before. So the âfixâ is saved to the items.
When splitting an item into two by pressing âReturnâ inside it, it should not be split if the only characters following the insert mark are whitespace.
Instead, a new item should be appended, just as when pressing âEnterâ at the end of the item. -
Search results do not change to include checked items (that match the search) when switching âChecked Items: Hideâ to âShowâ in case it was âHideâ while doing the search.
It works as expected though when searching with âChecked Items: Showâ set, and then switching back and forth between âHideâ and âShowâ. Since there is this difference, only one of the behaviors can be right. Namely the one when searching with âChecked Items: Showâ set. -
After deleting ones Dynalist account, a user will still appear in documents shared with that user as âName (name@example.com+tHy-1vxemnzu)â or similar, and removing that user from the sharing settings of a document fails with âYou entered an invalid email.â.
As a workaround, one can choose âUnshare this documentâ, then share it again with all pripor collaborators except the bogus e-mail address of the deleted account. -
When sharing a document with âtoo many peopleâ, the buttons at the bottom of the screen will become hidden and unusable as no scrollbar will appear as it should.
As a workaround, zoom out using the browser functions. -
HTML hyperlinks will not be preserved when copy & pasting to a browser.
The link will be inserted as Markdown source code. Other HTML in the rendered text, such as â** ⌠**â bold formatting, will be inserted correctly (here, as bold text) when copy & pasting. So itâs not a systemic issue. Tested in Google Chrome, with pasting to Google Docs. -
The date format â1hâ, â24hâ etc. works but is not documented.
-
âcreated:1dâ should search for everything created within the last 24 hours, not within the last 48 hours.
Currently, âcreated:0dâ can be used to search for everything created within the last 24 hours. But thatâs confusing, as âzeroâ of something is generally understood to be really zero, not âanything less than oneâ.
There should be an indication of what nodes are being edited right now, to prevent data losses through concurrent edits.
By having separate view and edit modes in Dynalist, it is possible to creates these indications in a more precise way as just scrolling in the document in view mode will not change the âwhat is being editedâ indication. -
The main content area is always more than 100% wide.
The fix, as implemented in our Dynalist userstyle:.is-desktop .Document { width: calc(100% - 67px); }
instead of originallywidth: calc(100% - 50px)
.
Suggestions
-
Listing the document creator as âOwnerâ in a document is not a helpful concept.
It confuses people, such as: Will the documents I own be deleted automatically when I delete my account, or will collaborators still be able to access them if I shared them? And: How can I transfer ownership of a document? And: What can an owner do that a manager can not do with a document? -
The default key combinations for "Zoom in previous item"and âZoom in next itemâ should be changed because they are confusing.
Square brackets are already associated with zooming in (Ctrl+]) and zooming out (Ctrl+[) respectively. Which makes graphical sense, so itâs logical. But then they should not be associated with zooming in only in this other set of keyboard shortcuts (Ctrl+Shift+[ and Ctrl+Shift+]).
Proposal: set âZoom in on previous itemâ to Ctrl+Shift+â and âZoom in on next itemâ to Ctrl+Shift+â. This makes graphically sense, because the previous sibling item to zoom in on is (in a more zoomed-out view) always above the currently zoomed in item, and the next sibling item is below.
In addition, the wording âzoom inâ should be avoided to make the shortcut more intuitively understandable in the help text. Because, zooming in implies focusing on a higher level of detail, while here the focus keeps on the same level of detail but is moved to the previous or next item. So instead, describe this function as âMove zoom to previous itemâ and âMove zoom to next itemâ. Or even âMove zoom one item upâ and âMove zoom one item downâ. -
There should be a âview modeâ similar to to the default mode in FreeMind, where one has to press a key to enter into edit mode.
This view mode should either be the default, or could be selected by the user at any time (while being by default in edit mode, such as after opening a document).
Proposal for keyboard shortcuts: Leaving edit and entering view mode would be done by pressing âEscâ. Leaving view mode and entering edit mode would be done by pressing âEnterâ.
The advantages of a âview modeâ include that navigating around with the keyboard is way more comfortable and optically more pleasing. Instead of having to move the cursor by a varying number of lines to move move to the next item in a list, one would only have to press âââ once. Also, since key presses are not meant to write letters in view mode, more keys are available for shortcuts, such as âSpaceâ (as a large, simple to reach key) for opening and closing a node. -
All punctuation should also be considered as ending a tag (@tag or #tag), not just a space character.
Tags should only be able to contain alphanumeric characters plus â-â and â_â. The first character not of these would mark the end when parsing for tags.
The current implementation is a bit like this, but inconsequential: â,â will terminate the tag, but not â.â or â)â.
Without this implementation, it is not properly possible to âuse tags like wordsâ in the text, as one canât use normal punctuation after them, having to insert a space before. This is ugly.
Seemingly, the only reason for the current implementation is that "#tag " can be used to search for just a tag and not for other tags that start that way, for example â#tagtagâ. However, that is a hack. People often accidentally place punctuation after their tags, and in some cases such as for appending â,â the tag-recognizing text backgrond formatting will show this as ok. However when clicking such a tag, it will automatically search for "#tag " and not find that â#tag,â occurrence.
When clicking on a tag to search for it, the search should result in âtag:#tagnameâ, not in "#tagname " as currently.
Because the current search canât find cases where the tag is followed by a punctuation character, such as â#tagname,â. Just â#tagnameâ canât be used either, as it would also find â#tagname-plus-somethingâ. So we need a new search operator.
To make using the new operator simple: when entering something into the search box that starts with â#â or â@â, proposals should appear according to the currently existing tags, using the new âtag:â search operator.