TaskPaper 3.0 Preview (171)

TaskPaper
1
  • Added ability to drag items into projects in the sidebar.
  • Option-Click to position cursor without opening any links.
  • Automatically escape spaces in file paths dragged into editor.
  • Better behavior when toggling auto-expanded items.
  • Better selection positioning when formatting item types.
  • Fixed bug when moving around folded items.
  • Fixed bug opening file paths that contain multiple spaces.
  • Fixed bug when undoing to an empty document.

Theming Changes

I’ve made changes to how themes work in this release. Previously there was a single file named user.less that stored all theme rules. The problem with this approach is that I couldn’t update the theme rules without overwriting customizations that users might have made to there user.less.

To solve this problem, going forward there are two theme files. There is now a base.less theme file included in TaskPaper’s application bundle, that I can update for each release. And there is a theme.less file stored in TaskPaper’s Application Support folder where users can define rules that extend the base.less rules.

This means that your theme.less themes should now (normally) be much smaller (then what was previously in user.less), because they don’t have to repeat all the base rules. Instead they only need to list the new rules/variables that they add or override.

Also in themes:

  • Moved editor.handle-color to item.handle-color.
  • Added sidebar.search-item-prefix style attribute.
  • Fixed parsing of quoted string values. So now "My Font" should work.
  • See the updated Creating themes for more details.

Download TaskPaper 3 Preview

4 Likes
2

Looks like this version has quashed all the movement bugs. :smile:

Separately, I notice that if i select a heading and its subheads (e.g. below) and if the whole structure is already fully to the left (heading 1 is fully promoted), then if i un-indent or move left, the subheads are promoted to the heading1 level. I think this is intentional on your part, but just want to point it out.

  • heading 1
    • sub1.1
    • sub1.2
    • sub1.3
1 Like
3

Huzzah! :dog: Thanks so much for fixing the selection positioning.

I’ve run into one problem customizing the theme, when trying to make top-level projects a different font size than sub-level projects. This is the code I used in the previous version that isn’t having any effect in this one.

item[depth="1"].item[data-type="project"] {
  font-weight: bold;
  font-size: 25px;
  color: rgb(79, 179, 209);
}
4

Sorry, I’ve taken out the ability to style items based on there containing items for now. I will try to add it back at some point, but it wasn’t fully working. There was no invalidation happening when the containing items changes, so depending on the style rules the child styles wouldn’t updated when needed.

5

Makes sense. Thanks!

6

Are individual tasks supposed to have project like handles as well? See attached photo.

7

Yes… I wouldn’t call them “project” handles, just “handles” :smile:. They have in fact always been there (just not visible). They define the region that you can:

  1. Drag and drop items from.
  2. Expand/Collapse items (if they have child items)

In previous versions I only showed them when an item had children. But I’ve changed my mind and like the “universal” look for a few reasons:

  1. It’s no longer a guessing game when trying to find the spot to drag and drop items from.
  2. It makes the item hierarchy a just a little bit clearer. There’s now no questions which items belong to which items in the hierarchy.

In the next release I’ve made them just slightly less visible (15% vrs 20%). With all of this said you can get the old behavior (or create your own) with a custom theme. Add the following to your theme.less file to get the old look:

item[leaf] {
  handle-color: clear;
}
1 Like
8

Make total sense. I just wanted to make sure that was in fact the intent.

Thanks!

1 Like
9

Another nice update, Jesse!

Thank you for accepting my suggestion to add a style rule for the lead character of the sidebar search items! :wink:

Does this new theming changes brake the possibility of setting our own variables? I was trying to use some variables to help me handle a color scheme through the theme file but whenever I set a variable different from the predefined ones (@font-family, @ui-scale, etc.) the theme breaks.

10

It shouldn’t. I was just messing with this in my theme file and it seems to work:

@priority-1-color: #ff6259; // red

.colorText(@color) {
  color: @color;
  > run[link^="button"] {
    color: @color;
  }
}

item[data-1] {
  .colorText(@priority-1-color);
}
11

Ops… PEBCAK!
I can confirm it is working.

12

Jesse: I do indeed like the “handles”, though… what about making “Note” handle different (smaller or lighter or… somehow “less visible”) than “Task” one? :wink:

thanks for listening :slight_smile:

13

You can change the colors a custom style:

item[data-type=note] {
  handle-color: mix(red, @background-color, 10%);
}

item[data-type=note].item[collapsed] {
  handle-color: mix(red, @background-color, 50%);
}

It sets up two rules. The first is for normal notes. The second is for notes that have children that are collapsed under the note. In this case I think the color should be brighter so you know there is hidden content.

1 Like
14

When a filter is applied, if you move items between projects using the keyboard move actions, it appears to work fine. However, after leaving the filtered view, you’ll discover the item was actually moved to a completely different project. I believe this is happening because each time you move an item up (for instance), it’s internally being moved up within the entire hierarchy, not just within the items shown in the filtered view.

15

I’m not sure that I follow. Can you tell me how to recreate the problem (what filter and what items to move where) in the default “Welcome” document?

16

To duplicate the behavior in the Welcome document, follow these steps:

  • In the project, “To Organize Items”, add a new item called “Test”. Move each of the existing items under the Test item. So, the hierarchy should look like:
To Organize Items:
    Test
        - To indent items press the Tab key.
        - To un-indent items press Shift-Tab.
        - To mark a task done click the checkbox.
  • In the “Welcome” project, tag the last item @today
  • In the “To Create Items” project, tag the last item @today
  • In the “To Fold, Focus, and Filter Items”, tag the last item @today
  • Apply the @today filter
  • Using the keyboard shortcut, move the item, “To filter your list enter a search in the toolbar search field” up once, so it lands in the “To Create Items” project.
  • Remove the @today filter

Upon removing the filter, you’ll see the item was moved to the wrong project. Instead of appearing in “To Create Items”, it appears in “To Organize Items”. I believe this is happening because the move algorithm must assume all hidden items are on the same level in the hierarchy. Adding the “Test” sub-item and indenting the items beneath it somehow messes up the algorithm.

1 Like
17

Thanks that helps me a lot. I think I’ve solved this problem for the next release. So please make sure to test once it comes out!

18

Hi Jesse,

It’s working fine in build 176

1 Like
19

Hi Jesse,

Exciting to get to grips with the previews of TaskPaper 3.0! My question, also on the handles: if each item is going to have one, is it also possible to hide the leading dash? Like the hiding of some Markdown in FoldingText, it could become visible only when being edited. I know you could no longer click to mark something as done – or at least you’d have to click an invisible item to do so – but I’d be happy with that. Not sure if this is a possibility, but would be interested to know if so.

Thanks as ever!

Mark

20

The way that I think about it I don’t think it makes sense to hide the dash… that’s part of the content that the user typed in. As described above you can hide the handles in various ways if you want.