»
TaskPaper 2.0 Development 53
Posted August 15, 2008 by jesse
in
development
- Added, Preference to not show default text in new documents.
- Added, Choosing color theme color for items in the sidebar projects list. Their color is taken from the themes foreground color.
- Added, Command-click on file hyperlink will now open the file instead of just revealing it in the finder.
- Added, Click on tag name to begin a search for all entries matching that tag.
- Added, Click on tag value to begin a search for all entries matching that tag and value.
- Noticed, You can build compound predicates for searching and theme rules by holding down option key, and then clicking the (+) button in the predicate editor UI.
- Changed, Default theme so that indented projects get bold formatting.
- Changed, Search status view now uses HUD style when HUD toolbar selecte in the theme.
- Changed, Keyboard shortcuts for next/previous project to Control-Command-Up/Down-Arrow. This means that you can once again use the default Command-Up/Down arrow to jump to the top or bottom of your document.
- Fixed, Crash on startup bug that was effecting some users.
- Fixed, Dash before tasks now is colored properly based on theme foreground color.
- Fixed, The .taskpaper extension is always added to new documents.
- Fixed, Themeing problems that caused random colors and attributes to be assigned to tasks.
- Fixed, Quick Entry window now uses theme background color, instead of always displaying white.
- Fixed, Project list popup (Command-L) now works even if TaskPaper window is on secondary screen.
- Fixed, Spell checking as you type should work normally now, instead of losing the highlight.
- Fixed, Drag and drop bug that would under some circumstances cause entries that were not part of the origina ldrag to get parented under the dragged entry.
- Fixed, Subprojects are now displays in projects sidebar, and properly indented. (They are also properly listed in Quick Entry Window)
Note, the new searches for both tag and value won't show up correctly in the predicate editor. So you can't build or edit them their, but you can create such a search by clicking on the value of a tag.
This version has been replaced by development 54
reply |
edit
Matthew Crider - July 1, 2008 3:13 PM
Jesse,
Lots of GREAT improvements! Well done.
Shouldn't this be the exact opposite? That is, command-click on file hyperlink will reveal the file in the folder and clicking a file hyperlink will open the file analogously to every other type of link in the known universe (ok, a little hyperbole there). Or, is this a Leopard issue?
Matt
reply | edit
Jordan Sherer - July 1, 2008 3:14 PM
One thing that has always struck me odd about TP2.0 is that you can't "see" what search you are currently viewing unless you:
Unless one of the two conditions are met, there is no indicator for which search view you are in.
reply | edit
jesse - July 1, 2008 3:36 PM
I agree it's a little odd. I'm going to start a separate thread for this.
reply | edit
jesse - July 2, 2008 9:06 AM
Here's a thread for thoughts on searching...
reply | edit
David Aguilera - July 2, 2008 10:57 AM
Should associated notes also display in a filtered view? If I use a criteria based on "any tag name" the resulting view only shows matching tasks, but no notes. My notes are indented, so I am not sure what may be going on.
reply | edit
jesse - July 2, 2008 11:08 AM
At the moment they shouldn't be, but I agree in some cases it could be useful. The problem with showing children of matching entries in the search results is that all of the sudden you'll get a lot more results. For example any project that matches your search will get all of it's contained entries added, and soon you'll be doing a lot of scrolling. Normally I use searching just to find something, and then use the reveal command to go to the full view where I can edit the result in context (ie with it's notes, etc)
reply | edit
michael walsh - July 2, 2008 11:46 AM
I like the reveal command. However, I find that it is awkward when I have to look under multiple items to find what I am looking for because I have to re-initiate the original search each time. It would be great if there was a "back" button or command that would take me back to the search results.
Having the option to show children notes could also work if the search does not turn up too many entries.
Regards.
m
reply | edit
Rob Cope - July 2, 2008 9:52 PM
FWIW, that is exactly what I want. I have been using tags on projects to track their context (@work, @home, etc), and when I am working in one or the other context, I would like to be able see all the projects and their associated items and notes.
This problem could be solved by using a different TaskPaper document for each context, but sometimes I also want to see the contexts all together (e.g. to get a general picture of what needs to get done today). Multiple documents don't work well in that case. The Quick Entry also doesn't work for multiple documents, but that's a smaller issue.
So anyway, this is a vote for an option to show the child items of parents returned in a search.
Rob
reply | edit
jesse - July 4, 2008 8:19 AM
The nice thing about changing to a query language is it will be fairly easy to implement these sorts of options. Nothing done yet though.
reply | edit
jesse - July 10, 2008 9:15 AM
Just noticed that I forgot to remove a few not yet implemented things from the predicate editor. Don't use "string value, number value, and date value" in the predicate builder, they don't really do anything (except crash the app) right now.
reply | edit
Amber Vaesca - July 10, 2008 11:33 AM
Is it possible to adjust the Opt-delete characteristic so that it will wipe out an entire tag in one shot? That is something that is always a bit annoying for me. I use a few status tags here and there, and removing them once a task has reached a certain point is always a little more difficult than it should be.
reply | edit
jesse - July 10, 2008 12:24 PM
Good point, the next release will be smarter about tags and forward/backward word delete.
reply | edit
Amber Vaesca - July 21, 2008 1:36 PM
Some feedback on the toolbar position: Are you really set on having it at the bottom of the window? This feels strange to me, but that isn't the major source of grief as I can get used to things being different. The frustrating thing is that drop-down menus are calculated by originating widget down, which means that if you have a TP window at near or full display height, you get all of four projects visible instead of a full menu. I (as intimated before on these boards) prefer typing to mousing, but even then the visibility of titles serves as a memory aid in cases where the first few letters of a project name might elude you.
reply | edit
jesse - July 21, 2008 2:24 PM
I was set on having it at the bottom, but that's changed. In the next release (still a ways off) TaskPaper will have a new query language. And for me that changes the value of the search box. Previously I didn't think the search box was very important, now I think that it's very important. Because of this I'll be moving the search box (and everything else) to the top of the screen.
I'm still trying to figure out exactly how I will do it. I don't want to just put it all in a toolbar. I'm thinking that I'll just place the search directly above the TaskPaper text area... anyway the point is that it will be going back to the top. Just not sure how it will look yet.
reply | edit
Amber Vaesca - July 21, 2008 3:31 PM
That's fantastic! I mean it will be nice to have the menus drop down instead of up, too, but the query language. I wish all programs would beef up their quick-searches with proper syntax. Thanks in advance. :)
reply | edit
cthulhu75 - August 2, 2008 8:35 PM
This may be a dumb question (and answered elsewhere), but is the v2(53) development version working towards the anticipated 1.1 release, or a longer term 2.0 release (and v1.1 scrapped)?
reply | edit
jesse - August 2, 2008 8:54 PM
It's working toward 2.0. 1.1 has been scrapped, or really it's been renamed 2.0.
reply | edit
cthulhu75 - August 2, 2008 9:19 PM
excellent - i've been playing with this v2, and so far it's stable as a rock. its also already head and shoulders above 1.03 (which i tried as well). keep up the great work - can't wait for the release!!
reply | edit
jmz - August 11, 2008 4:53 AM
The scollbar is bugged. My OS is configured to show both of the scrollbar arrows at the bottom, but despite this TaskPaper shows arrows at top and bottom. There is a gap at the bottom (which is not drawn at all) as a placeholder for the up arrow. When the slider is at the top, it covers the up arrow drawn by TaskPaper. Plus the slider is different colour and style than normal scrollbars in OS X.
reply | edit
jesse - August 11, 2008 7:09 AM
I'm not sure why this is happening. But I think you can fix it by going to the OS X preferences for scroll arrow location, and toggling the value. Doing that seems to permanently fix this problem.
reply | edit
RobAllen - August 13, 2008 8:19 AM
Hi,
First time I've looked at 2.0 and I'm very impressed so far. It's a good step up from version 1.
Some thoughts:
I was looking at the plugin system. Would these sort of things be possible to do as a plugin?
Regards,
Rob...
reply | edit
jesse - August 13, 2008 12:42 PM
On my list, but it's a big list so I'm not sure if it will make 2.0. One issue is finding the right keyboard shortcuts... alt up/down is already a standard for jumping to beginning and end of lines.
This should be already working. But to get dragged the notes and tasks need to be indented (tab) under the dragged tasks. Also for now if you have a blank line (that isn't indented, then any trailing notes and tasks won't be dragged.
Thoughts on this are being put off until after 2.0.
Right now it just goes into the front most document. But I agree it does seem to make sense to allow for redirecting that behavior. I'll add it to my list.
Probably not without a lot of work. In the end anything is possible with the plugin system since you code will be loaded into the process. But the public api will be pretty similar to the applescript API, just a lot faster and easier to use. So plugins will be able to manipulate tasks, add menu items, etc, but they won't be able to easily change the apps UI behavior.
reply | edit
Matthew Crider - August 13, 2008 1:13 PM
Jesse,
This is another reason why the indentation protocol needs to be looked at. Have you had a chance to look at my sample yet?
Matt
reply | edit
jesse - August 13, 2008 1:21 PM
Yes I've taken a look and think it makes sense. I still haven't got around to implementation, that might bring up some issues, but your general push to have tasks visual indented under projects seems solid and doable.
reply | edit
Matthew Crider - August 13, 2008 2:28 PM
Fantastic!! Thanks, Jesse.
Matt
reply | edit
RobAllen - August 14, 2008 2:13 AM
This should be already working. But to get dragged the notes and tasks need to be indented (tab) under the dragged tasks. Also for now if you have a blank line (that isn't indented, then any trailing notes and tasks won't be dragged.
Aha!
Thank you!
Regards,
Rob...
reply | edit
Topic's comments