Recent changes to feature-requests

More intuitive selection

briareus — Wed, 18 Apr 2007 09:53:03 -0000

Right now, it seems that a node has to be completely inside the selection field in order to be selected. This leads to some strange cases, such as the selection in the attached picture only capturing Y1 and X nodes. Can this be changed so that nodes only have to intersect the selection area in order to be captured?

Save/Load memory

briareus — Wed, 18 Apr 2007 09:48:22 -0000

Could the Save and Load functions be made to keep track of where files were saved/loaded last and open in that directory?

Keyboard shortcuts to write over null heads

briareus — Wed, 18 Apr 2007 09:45:41 -0000

Right now, null heads can only be overwritten by mouse-dragging another structure on top of them (generally from the list on the left, when constructing a tree). This is both time-consuming and potentially problematic (in combination with the bottom-of-the-screen bug). Right now, when a keyboard shortcut for inserting a structure is used at the mother of a null node, that structure can only be inserted as a sister to the null node; would it be possible to include the null node itself in the list of possible positions, and have the new structure overwrite it when that option is selected?

"Cancel" option on the "Save trees first?" dialog

briareus — Wed, 18 Apr 2007 09:44:33 -0000

More than once, I had several windows open and clicked to close the wrong one - then had to save it, let the program close it and then reopen it. In cases like this, it would be convenient to be able to simply cancel the closing and continue working.

...also, this may be my intuition from years upon years of Windows, but I often read the current "Yes/No" selection as a response to "Do you really want to quit?" and catch myself just before I press "No".

No save prompt if the tree hasn't been edited

briareus — Wed, 18 Apr 2007 09:38:11 -0000

Right now, TreeForm pops up with the "Save trees first?" dialog even if no changes have been made to the tree. In these cases, it seems to make more sense not to prompt.

Keyboard navigation beween nodes

briareus — Wed, 18 Apr 2007 09:30:39 -0000

Would it be possible to implement keyboard navigation between the nodes? Right now, a node has to be selected by the mouse, then edited - then the next one selected by mouse and edited, etc.
I don't know how the text selection works by default, so the below may not be feasible, but here's how I'm picturing it:

--Arrow keys are used to navigate - left and right for switching between sister nodes, up to go up to the mother node, down to descend to the leftmost daughter. (Or central, or rightmost since most trees have a heavy slant to the right. Maybe a program-wide user-changeable setting?)
--When a node is navigated to, all of its text is auto-selected; if the user presses an arrow key they move to another node - if the key pressed is alphanumeric or Delete/Backspace, the text at that node is overwritten and they begin editing it. (Perhaps also another key, i.e. Enter, to start editing without overwriting?)
--In edit mode, up/down makes the cursor leave that node and switch as with regular navigation. Right/left depends on the position of the cursor; if, say, the text is "drop" and the cursor is left of the D and told to go left or right of the P and told to go right it leaves the node and behaves as with regular navigation. Otherwise, left/right just move the cursor within the text at that node, same as they do right now.

It would also be nice if left/right could navigate between branches, not just immediate sisters - i.e. between X3 and Y3 in the image.

Support for copy/paste into OpenOffice word processor

briareus — Wed, 18 Apr 2007 09:25:20 -0000

...would be very much appreciated. =)