[BwanaZulia]

I really liked the option in the inspector for each task/project that simply says "Archive" it should be on by default but if turned off, those tasks, once done and are not archived.

So for your every day/hour/week/month tasks yuo can simply not have them archived.

Easy Peasy.

BZ

[dashard]

I'm no programmer, but I am a highly skilled professional thinker. :-)

My idea would be to have OF treat archived items differently. Not address them until *I* address them. That is, while I'm working in my day-to-day and not looking at past triumphs, to not have them addressed via the program or memory space. Some virtual sequestering, if you will.

When I invoke a view that has my archived items, or if I click the tick-box to include archived items in a search (like that little feature request just sliding in there??) then and only then are they referenced by the program and its memory space. Then and only then will they be addressed, and when I exit the view or the search, etc, ideally they would be pruned from the active heap and sequestered again.

Does that make sense?
Of course, this might be completely impossible from a programming standpoint. Perhaps tracking archived items in a separate but parallel db?

FWIW.

[curt.clifton]

dashard,

That's some impressive thinking!

It accomplishes an essential part of what Liz is asking for and would integrate nicely with the UI. I think it also matches Amber's request when combined with filters. For example, I could filter to just show the mundane completed tasks that I don't care to see again. Then I just Select All and Delete; that's equivalent to a purge. Next I could filter to show the old completed projects that I might refer to someday, using whatever definition of "old" I like. Again a Select All, but this time an Archive; the system moves the projects into the archive and out of my way.

Maybe you should take up programming. It's a lot of fun! Your parallel database idea would be a reasonable approach. It would slow the program down when Display Archived Projects mode was on, since all queries would have to be sent to both databases. But it would keep the system fast in normal usage.

Cheers,

Curt

[AmberV]

Putting everything into a completely different database would probably be overkill. I could definitely see moving archived things into different tables within a single database though. That keeps the current queries snappy, and table joining is second nature for a database; very fast and simple. If you want to see everything together, it would really only add the query time of pulling out however many thousands of old items exist in the archive.

[coconino]

Projects are only marked as complete when the user explicitly marks them as such. Merely checking-off the various actions in a project does not complete a project; the user has to change the project's state via the Project inspector or via the pop-up menu when control-clicking on the project icon. When projects are marked as "Completed" they are filed out of view of the "Active Projects" filter and are effectively archived.

My usual operations are done with the filter set to "Active Projects", and I seldom change this. It keeps stuff which is done, or on long-term hold (not just "awaiting", because those are still active projects) out of sight but still easily accessible if I need it.

[brab]

Originally Posted by AmberV

Putting everything into a completely different database would probably be overkill. I could definitely see moving archived things into different tables within a single database though. That keeps the current queries snappy, and table joining is second nature for a database; very fast and simple. If you want to see everything together, it would really only add the query time of pulling out however many thousands of old items exist in the archive.

I would like to purge my database as well, but I agree that a different database is too much. What I would like is a simple text or rich text (or OmniOutliner) dump to keep around for history purposes.