I’m having a hard time identifying the items in my database based on the short string of characters that fits in the sidebar. Is it possible to change the view it so that the item browser takes up the full width of the screen, not just the sidebar? Screenshot below to illustrate what the view I’m stuck in. image|375x500
And grid view is even worse, because it displays even fewer characters from the item name.
I don’t think this is currently possible. I’d like to see the same functionality too. I think some tweaks in the “grid view” to allow it display lists would suffice.
Did you try to raise the number of shown rows (click the right most button, then „Preview“)?
(I don’t use iPad so can’t test)
Unfortunately, the split view controller that all stock apps use, and DEVONthink To Go too, does not allow the user to change the widths, contrary to the Mac.
This is also a good case supporting our advocacy of shorter filenames…
What about expanding the full screen grid view to allow a list view as well? I understand the benefits of short filenames. But sometimes the files need to be identifiable by the filename alone when it’s leaving the DT system without extended metadata. And sometimes the filenames are determined by other sources, like the original author.
Understood regarding the filename but also remember such a change to the UI wouldn’t be a simple matter. It also has to work on smaller iOS devices as well.
I was mostly thinking from the perspective of ipad. But I couldn’t imagine how a fullscreen list view wouldn’t work on an iphone. I’m also not sure if the ipad ui design should be limited by that of iphone, considering we have very distinct ui on ipad and iphone already.
Although it might be true it’s not as trivial to implement as I imagined as I don’t understand the complexity of the development.
It’s my understanding, and of course I could be wrong, but I understand from credible sources that any development on Apple’s iOS is non-trivial. More complex rules, conventions, lots of security, etc. As it’s not a real computer, amazing that it works!
As pointed out by @rmschne, development for iOS is non-trivial. It’s also non-trivial on the Mac but on iOS the restrictions imposed by the OS are higher and many APIs that we do have available on the Mac are not there on iOS.
And, in addition, it’s also a matter of priorities.
