Groups losing state visibility on move

I have recently begun to use DT for GTD and have considerably more “show state” groups then I have ever had before and am running into annoying problem. If I move a group (showing state) to another group folder, the state turns off and the moved group becomes a regular folder again. The workaround is having to re-enable state showing on every object that is moved… and in GTD this is the most common occurrance.

Is there a way to keep state enabled without having to lock it first – which is just as cumbersome because each moved group would have to be unlocked after the move anyway.

Not that I’m aware of.

I’ll note this to Christian as something to think about. We’ve had similar requests in the past.

At least from me. :slight_smile:

Btw, the Show State flag is set on merged documents even if it’s unset on the original documents. Also, trying to merge HTML documents will cause DT Pro to crash.

I can provide more details about that later, if necessary. Right now I’m short on time, preparing to take my iMac to the Apple Store for their diagnosis of trouble with a FireWire port and at least one hardware sensor.

I think this only happens if you move an outline-group/file to a non-outline-group - if you move it to another outline-group the checkbox remains visible. Im not sure if its a bug or a feature :wink:

My problem with checkboxes is, that for me they react to slow.

Hmmm… I think this is a bug, as users should not have document “states” automatically changed on them. This same issue as been annoying me recently too – I happen to like keeping a list of checkbox items within actual folder groups, and the disappearing status box as I reorganize items is a bit frustrating. Christian, what’s the final word on this issue?

Christian,

I know you haven’t had time to reply yet to my question above. But since posting it I have thought of another very good reason to “fix” the problem reported above about the state being lost upon move into a Group that does not show the state:

Abandoning NoteBook and others I used to use for this purpose, I have started keeping “To Do” lists in DT. I am suprised how much I like it and how DT features make this useful in unexpected ways. I never used to use the State checkbox, but now I do – but only for short “To Do” items, basically I am using the State box as a kind of “metadata tag”. It is useful to assemble in one Group various To Do items with the State showing, along with other DT docs related to the project or task. I like seeing the difference between a To Do item and other docs at a glance – hence there is a lot of intermingling between states shown or not in this set-up. By seeing the difference of these two types of docs I can quickly delete To Do items, but keep the other docs for permanent reference in my database. The automatic state showing/hiding that occurs now is confusing for this kind of workflow.

Does this make sense? I am hoping the current behaviour is just a bug, and if it’s not, then could you please make it a Preference to “Show/hide State according to parent Group”? Thanks.

It’s actually not a bug, this was requested in the past. The visibility of the state is “inherited” from the parent group and therefore moving an item to a different group adapts the visibility. However, if everyone agrees, I could modify this (but creating new items in a group will still use the visibility of the parent group of course).

That’s not a bug of DT, that’s one of the new WebKit and depends on the HTML documents - sometimes it works, sometimes not. Maybe the latest version (Safari 2.0.1/1.3.1) fixed this?

Christian, Thanks for the response. I can understand how different users might want it to behave in different ways. For myself, I would prefer that items moved (or replicated) into a Group keep their own state. *** If possible, having this as a checkbox Preference: “Inherit parent Group’s state upon move (or replicate).” should make everyone happy and allow each user to determine the behaviour he/she likes best for their own usage.

I agree, this makes sense in both scenarios.