Looking at it again, I guess that setting the position and size of both app document window and extension NSPanel might also need frame reading and writing for the app windows themselves, in addition to writable x, y for the panelHandle interface ?
1 Like
when pasting text under a heading, why does Bike add an empty child row beneath the parent? I discovered that if I place the cursor at the end of the parent row, i can avoid the empty child row, but this isn’t so intuitive
1 Like
Delete Row
Shouldn’t Delete Row delete only the focal row in Text Mode (leaving behind any children) but delete the focal row plus any children in Block Mode? That seems more logical to me (it’s also what Taskpaper does, and maybe what Bike 1 did, can’t remember).
For instance, sometimes i want to put to delete a parent to put its children under another parent. It’s convenient to just delete the parent first.
I realise that what i seem to be requesting is for Bike2 to act like Taskpaper in Text mode and to act like a more industry standard outliner in Block mode.
I use outlines to help me think, which means that I am constantly changing the structure at both micro and macro scales. That favours very granular editing, like TP, even if i have to clean up manually.
Later, when the structure is largely settled down, i want efficiency in moving things around, and that favours block mode.
I’m working toward this option, and this is how Bike 1.x worked.
It was also one of the bigger complaints/misunderstandings that I saw. I agree it’s an interesting/nice way to work, but it’s also unfamiliar. In particular it confused many long term outliner users (people who I think would get great benefit from Bike) making them think Bike wasn’t really a full outliner. Didn’t work like it should.
I think Bike 2.0 will continue to default to current “pure outliner” behavior. But I will also include “text” based outlining commands (as I have been, but I’m continuing to improve those for next release).
To get the behavior you are looking for you will need to override the default move command shortcuts, remapping to the “text” based move commands. If you do this just for text mode then you will get the behavior you want. Text command in text mode and outline commands in block mode.
that works for me. I’m happy to remap keybindings.
my latest wish then is to be able to promote/demote (i.e. left/right move) a single line.
to go from this
to this with a single keystroke in the subhead row.
1 Like
I think that should be possible now with “Row: Text Indent” command. There’s also “Row: Text Outdent” to go other way.
kind of works, but Row:Text Outdent drags any children along to the left, and Row: Text Indent does not let me “over indent” (i.e. indent more than one level).
Do you think it would be useful for more than just a handful of users (myself included) to ship some kind of settings file that would have text manipulation commands mapped to 1.x text mode behaviour?
I really enjoyed working in Bike’s text mode. Never really understood the confusion/criticism around “proper” outliner behaviour.
1 Like
I tried building an extension for nested row counters (e.g. 1.1., 1.1.1. etc.) today, but it looks like it’s still unsupported in the API. Is this a post-2.0 thing?
/** Get counter value */
//getCounter(name: string): number
/** Get nested counter values */
//getCounters(name: string): number[]
Incidentally, I managed to reproduce an unresponsive expand/collapse handle issue:
- Paste below into outline (anywhere)
Something
Something else
Something else
Something
- The outline should come out partially collapsed
- The first click on the expand/collapse handle will not expand the collapsed row
- Subsequent clicks will expand/collapse normally
EDIT on above issue: It seems that this unresponsive-handle-on-first-click applies to all rows that appear collapsed on paste. It’s almost like Bike thinks they’re expanded but shows collapsed state instead. If you zoom into a collapsed-on-paste outline, it will appear expanded and remain this way once you zoom out.
I’m not sure, I need to investigate and decide. Currently you can’t do (1.1, etc). The ways it might be possible in the future are that generic counter API. Or I might just provide context.orderedIndices, which returns hierarchy of ordered indices containing the current ordered. Not quite sure how hard that will be to add.
I think this is fixed for next release. Fingers crossed that will be later today.
1 Like
I think all issues in this thread (except paste creates new row) are addressed in one form or another. Let me know if you think more adjustments are needed.
1 Like
If you are pasting more then a text fragment Bike currently just inserts the new rows. Doesn’t try to combine with existing rows. This is for various reasons (easier!), but I should probably go back to combining first pasted row with existing row. I’ve added to my list.
This is now possible in latest release via context.consecutivePath. That path is tracked for ordered rows and heading rows. The last number in the path is for the current row. If the row also has numbered ancestors they will be provided earlier in path.
I was able to get 1.1, etc working, but you’ll quickly run into layout problems I think. The numbers will soon start to overlap text, outline controls. Not sure if their is a great solution without adjusting the layout at pretty deep level. (which you can do via stylesheet, but even then I don’t see any solution that I love … I like having guide lines, and they limit space availible)
One thing this does allow for is different number types at different levels. So for example depending on path length you could use 1, 2, 3. Or a, b, c. I think that would be fun to try.
1 Like