More explicit window names

Dear Devon,

I’d love more explicit window names to be able to navigate to them with the least possible ambiguity.

Context:

  • I often have 5-10 DT (3.0.2) windows open: Inbox of some databases, some documents, tags list, Some groups I always get back to, …
  • I use https://manytricks.com/witch/ to navigate between windows by name – same need that someone using the DT sub-menu “Windows” would have.

Issues (in order of importance for me):

  • When in the (left) navigation panel the inbox of database “Alpha” is selected (under “Inboxes”), then its name becomes, “Alpha - Alpha”, which does not tell me it’s the inbox of Alpha.
  • I do not know wether the window name represent a group, a tag, a document of which kind.
  • When I have selected a Group, its ancestry does not show up ( I know there’s obviously length limits to this).
  • When i have opened an epub in the mode “Best alternative”, the window title is “Cover”, and does not contain the document name anymore.

Thx!

There is very limited room in a window’s title bar.

You can Control-click the window title to see its location in a database.
image

And you can even select the parent items to jump to that location.

Thank you for those tips.

Will you still consider the feature requests or do you deem it unnecessary?

Regards,
b.

It’s not my place to deem something as unnecessary (or necessary). Requests that are made - here and elsewhere - are all considered. That obviously does not mean implemented, but they are definitely read and noted.

1 Like

And that’s all I ask for.
Thx!

The next release will fix this.

2 Likes

Thx!

Another very related request:

Window title of a window in “search mode” (where some search has been done and search results are displayed) should represent the search query and modifiers.

Ex: When I search for "insight tag:Leadership" in “MyLittleDatabase”* then window title ideally reflects this information so that i can navigate back and forth from one result (or other DTP windows) to the search results.

This would only be manageable in very short searches like your example. This wouldn’t scale well with more complex searches.

Indeed.

Luckily we humans have invented suspension dots.

My gut feeling would be that modifier is less important than query, so query first, concatenated with modifier, the whole cut at X chars.

+1