Between quits-and-startups. I have everything nicely arranged; I quit; I restart DTP via the Dock; it properly loads the last open DB; but the window positions are wiped out: it’s the same three windows.
Where is this prefs file stored? Why is it not updating? I did a clean system install and then dragged my old prefs into ~/Library/Preferences. Is there something I need to do? Should I kill my prefs and let DT rebuild them from scratch? Would that help?
I always have several DT Pro Office windows open, one of which is aligned to the right side of my screen. The windows and their positions are always recreated when I launch DTPO 2.
I have Preferences > General - Startup checked to open the windows that were open when last quit, and the option under Interface in that tab checked to ‘Retain View’.
In DEVONthink, click on the application name and choose ‘Empty Cache’. Quit your DEVONthink application. Try removing the Preferences file located in /Home/Library/Preferences/ that’s named ‘com.devon-technologies.thinkpro2.plist’.
Relaunch DEVONthink. Does the problem persist?
Documentation says:
Retain view: When the above option, Always open groups in a new window, is unchecked, this option keeps the actual view settings when you navigate the group structure instead of applying the group’s individual settings.
So, it’s not related to saving DTP window sizes/locations between sessions.
I’ve been struggling with window size/location issues when opening multiple databases while DTP is running. It’s still not obvious to me when opening a db will use the current window or open a new window (with its previously opened size/location). In general, managing windows for multiple databases has made hard to predict when sizes/locations will be changed or retained. Here’s a basic scenario of this issue:
• DTP launches with the global Inbox database open in a window
• File > Open Recent > db opens db in the current window previously used by global Inbox
• File > Close Database closes db and global Inbox reopens in the current window
• Command-W closes the window
• File > Open Recent > db new opens db with a window with a previously saved (and desirable) size/location
However, I’ll eventually manage to have done something where opening db when no other windows are open will use a different size/location than the desirable one mentioned above, e.g. inherited from the global Inbox window’s size/location. Scale this to several databases with multiple windows open and it drives me batty trying to predict what’ll open where, both within a single session and across sessions.
If nothing more I’d like an explicit “Open database in New Window” command, if it’ll help ensure the previous (desired) window size/location will be used.
Perhaps it’s my method, but possibly also the implementation, of working with multiple databases and windows that needs to be revised so it’s more comfortable and predictable. I think Demogorgon might agree with that, too. And I’ve noticed other posts I could correlate with this, e.g. the behavior of Data > Reveal (Command-R).
Frankly, I still feel too little attention is given to polishing DTP’s interface that could make it less of a chore and more of a pleasure to use.
Thanks guys.
First, yes, I had Retain View checked, of course. I’ve turned Groups in New Window on and off. It makes no difference in view-retention.
Well, I tried Bill’s suggestion. What happened BEFORE was that the SAME configuration was recreated every time. That is, something I wanted a week ago kept forcing itself into reality, no matter what the configuration of window was when I quit. What happens NOW is that I get the proper WINDOWS, but their size and position is all messed up – i.e., they are maxed-out in size and tiled left to right.
I did not have ANY of these problems until I did a clean system install. I did a fresh DTPro beta install, entered my license, and started her up. Ever since then, I have not been able to keep position and size of windows, though Bill’s tip at least gives me a layer-cake of the proper windows maxed-out.
Programmers? Does knowing that this kicked-in only after a clean install give you any ideas?
This behavior is something that I reported a couple of months ago in this thread:
And by another user in this thread:
In my case the problem still exists, even after creating a new database and copying all records to it, then deleting the offending database.
I like to have different databases open at different positions with different sized windows and for a couple of them to jump to the upper right corner when I know I’ve repositioned them is really annoying, not to mention startling when it happens.
I’m running DTPO PB5, OSX 10.5.7, and don’t have any third-party haxies installed.
Yes! I’ve also had the upper-right problem! Just today, before I did the plist deleting and cache clearing, one of my windows would be 90% off-screen, upper-right, just like you said. I’d shrink it, put it in middle, quit, restart, and it would be maxed-out and almost completely off-screen.
But this only started happening after I reinstalled Leopard and installed DTPro from a freshly downloaded image. What the hell??? You’d think things would have improved.
Unfortunately I don’t recall any specific system-altering events prior to noticing this happen. Also unfortunately, I tend to not notice such things for a while until it jars me once too often, so I’m left wondering WTF myself but not having the recent history in mind as you do.
Hey Eric/Christian/Bill and Twix! Here’s some good news:
(1) I went through Time Machine and inspected my database’s Package Contents from the days when DEVONthink used to preserve window sizes/positions. These good databases LACK certain files that my current nightmare database CONTAINS, namely, files containing “conflicted copy” in their filename. My current nightmare database has three “conflicted copy” files: two of type DEVONthink.lock', one of typeDEVONthink-1.dtmeta’, and three of type `Settings.plist’.
(2) As an experiment, I moved the contents of all top-level folders to newly made folders (given the same names) and killed the old folders whose sizes/positions DT could not remember. This worked.
This information should definitely help your programmers kill this awful bug.
Also, what is the relation between the “conflicted copy” files and window bugginess? If you don’t know, could you at least explain the purpose and origination of the “conflicted copy” files? Can I delete them? Do they arise when I change the name of my computer (in Sharing) or what?
*** UPDATE ***
This “fix” is not working anymore. It worked for two quits-and-relaunches. Now a relaunch produces maxed-out windows, tiled on the left side of the screen, and a few windows far to the right (almost entirely off-screen). I’m absolutely dumbfounded. Sorry everyone.
Dear DTP programmers,
Why is it so hard to fix this? Your inattention to such a simple problem has forced me to solve it myself, with an AppleScript workaround. The actual code is between lines of asterisks (don’t copy the asterisks into your scripts).
(1) Make a folder called “Other” in your HOME SCRIPTS FOLDER (~/Library/Scripts/). Save the following therein as “DT_props.scpt”:
property newDevonList : {}
property oldDevonList : {}
SAVE THE FOLLOWING THREE SCRIPTS IN YOUR DTP SCRIPTS FOLDER (~/Library/Application Support/DEVONthink Pro 2/Scripts):
(2) This one SAVES all open window information. Save the following as “saveWins.scpt”:
set scripts_path to (path to scripts folder) as string
set propScriptPath to scripts_path & “Other:DT_props.scpt”
set propScript to load script file propScriptPath
set win_list to newDevonList of propScript
tell application “System Events” to set visible of process “DEVONthink Pro” to true
tell application id “com.devon-technologies.thinkpro2”
copy win_list to old_list
copy win_list to new_list
copy windows to raw_wins
set all_wins to {}
repeat with next_win in raw_wins
try
set next_id to id of next_win
if next_id is not -1 then
log "MADE IT"
set end of all_wins to next_win
end if
end try
end repeat
set next_props to {}
repeat with next_win in all_wins
set counter to 0
set prop_index to 0
set next_id to id of next_win
set next_name to name of next_win
set next_bounds to bounds of next_win
try
set next_root to root of next_win
on error
set next_root to -1
end try
-- ERROR: Can’t make «class DTpr» id 2.147483645E+9 of ...
-- log "NEXT ROOT: " & next_root
try
log "NEXT ROOT: " & next_root
end try
if next_name is not "" then
log "GOOD WINDOW"
set next_props to {next_id, next_name, next_bounds, next_root}
-- Find index of prop-list to replace.
repeat with next_old_prop in old_list
set counter to counter + 1
if (item 4 of next_old_prop is next_root) then
set prop_index to counter
exit repeat
(* This was making too many dupes.
if (item 4 of next_old_prop is next_root) and ¬
(next_old_prop contains next_name) then
set prop_index to counter
exit repeat
*)
end if
end repeat
if prop_index is 0 then
set end of new_list to next_props
else
set item prop_index of new_list to next_props
end if
end if
end repeat
end tell
set newDevonList of propScript to new_list
store script propScript in file propScriptPath with replacing
show_list(new_list)
on show_list(the_list)
set show_string to “”
repeat with next_list in the_list
set next_id to item 1 of next_list
– set next_name to item 2 of next_list
set AppleScript’s text item delimiters to {" — “}
set next_name to item 2 of next_list
if text item 1 of next_name is “KantDiss” then
try
set next_name to text item 2 of next_name
end try
end if
set AppleScript’s text item delimiters to {”"}
– set AppleScript’s text item delimiters to {" “}
set next_bounds to (item 3 of next_list)
set x1 to item 1 of next_bounds
set y1 to item 2 of next_bounds
set x2 to item 3 of next_bounds
set y2 to item 4 of next_bounds
set next_root to item 4 of next_list
set show_string to show_string & next_name & " "
– " (” & x1 & “,” & y1 & " • " & x2 & “,” & y2 & “)” & return
end repeat
display dialog show_string
end show_list
(3) This one RESTORES all window sizes and positions. Unopened windows are, of course, ignored. Save the following as “restoreWins.scpt”:
set scripts_path to (path to scripts folder) as string
set propScriptPath to scripts_path & “Other:DT_props.scpt”
set propScript to load script file propScriptPath
set win_list to newDevonList of propScript
tell application “System Events” to set visible of process “DEVONthink Pro” to true
tell application id “com.devon-technologies.thinkpro2”
copy windows to raw_wins
set all_wins to {}
repeat with next_win in raw_wins
try
set next_id to id of next_win
if next_id is not -1 then
log “MADE IT”
set end of all_wins to next_win
end if
on error
set next_id to -1
end try
end repeat
repeat with next_old_list in win_list
set old_id to item 1 of next_old_list
set old_name to item 2 of next_old_list
set old_bounds to item 3 of next_old_list
set old_root to item 4 of next_old_list
set counter to 0
repeat with next_win in all_wins
set counter to counter + 1
try
set next_root to root of next_win
on error
set next_root to -1
end try
-- if (name of next_win is old_name) and (next_root is old_root) then
if (next_root is old_root) then
if (name of next_win is old_name) then
set bounds of next_win to old_bounds
end if
(*
-- Prevents all orphans from getting same resize.
if (next_root is -1) then
if (name of next_win is old_name) then
set bounds of next_win to old_bounds
end if
else
set bounds of next_win to old_bounds
end if
*)
(*
if counter is 1 then
set all_wins to (items (counter + 1) thru end) of all_wins
else if counter is (count of all_wins) then
set all_wins to (items 1 thru (counter - 1)) of all_wins
else
set all_wins to (items 1 thru (counter - 1) of all_wins) & (items (counter + 1) thru end) of all_wins
end if
*)
log "COUNT: " & (count of all_wins)
end if
end repeat
end repeat
end tell
(4) This one SHOWS all open window information. Save the following as “showWins.scpt”:
set scripts_path to (path to scripts folder) as string
set propScriptPath to scripts_path & “Other:DT_props.scpt”
set propScript to load script file propScriptPath
set win_list to newDevonList of propScript
show_list(win_list)
on show_list(the_list)
set show_string to “”
repeat with next_list in the_list
set next_id to item 1 of next_list
– set next_name to item 2 of next_list
set AppleScript’s text item delimiters to {" — “}
set next_name to item 2 of next_list
if text item 1 of next_name is “KantDiss” then
try
set next_name to text item 2 of next_name
end try
end if
set AppleScript’s text item delimiters to {”"}
– set AppleScript’s text item delimiters to {" “}
set next_bounds to (item 3 of next_list)
set x1 to item 1 of next_bounds
set y1 to item 2 of next_bounds
set x2 to item 3 of next_bounds
set y2 to item 4 of next_bounds
set next_root to item 4 of next_list
set show_string to show_string & next_name & " "
– " (” & x1 & “,” & y1 & " • " & x2 & “,” & y2 & “)” & return
end repeat
display dialog show_string
end show_list
Come on programmers! How hard can this be to fix? I can’t believe no one can figure this out. Would you like to send me the code? Please let me know. The fact that I have to run a position-saving and a position-restoring script manually is really sad. This problem is over six months old and NOTHING has been done. Each update is as dysfunctional as the last.
Demogorgon, if the issue could be replicated on a Mac with an essentially stock operating system, I suppose it would be straightforward to address it with programming.
As noted, I keep a number of windows open in several databases and they retain their sizes and positions each time DT Pro Office 2 is launched. And if I’ve modified the set of open windows in a session, the modified set is recreated next time I launch DT Pro Office 2. It ‘just works’ for me.
As a test, I made copies of that set of databases and opened them. The sizes and positions of the windows that were open were as I expected. I modified the set of open windows. Then I Force Quit DT Pro Office 2. On relaunching, the set of copied databases was reopened, but only one window was open. I’m not surprised, as the databases were not properly closed.
Another variable may be the software environment of a computer. At least one user reports that the position and size of windows on one computer is correct but window sizes and positions are not correct on a different computer, when the application is launched on the two computers.
My guess is that the issue is one of software environment – something installed that creates errors.
For various reasons, developers will always be unable to reproduce and fix every problem that’s reported. Seems unreasonable to assume and expect otherwise.
And as previously suggested in other threads, using the generic Guest account (if feasible) can be helpful for at least isolating whether problems are user-specific or system-wide.
Even though Christian hasn’t been able to reproduce it (yet), running DTPO under Guest made it easier for me to figure out at least the partial cause of a column (re)sizing display glitch.
Interesting developments in this thread.
In my experience, when I had a particular database open at the same time as several others, if I’d select that DB by selecting it under the Open Databases list, that window, while switching to that specific DB, would jump to the far upper right side of my 23" monitor. Selecting other open DBs from any other DB’s window didn’t behave that way. And it didn’t matter which other DBs were open alongside the troublemaker, selecting that troublemaker would always produce the same unwanted behavior.
Here are a few observations:
Made a SuperDuper! clone of this Mac to another and tested it, the behavior disappeared.
Copied the databases to the “Guest” account on my primary Mac and ran the test: Behavior disappeared.
I finally created a new database and moved the folders from the troublemaker. The bad behavior had disappeared!
Conclusion:
Who knows? Earlier I had run the “verify & repair” tool with no change. I began a thread here and added comments to similar threads, all to no avail.
@Demogorgon: You might have similar results if you try my three tests above. Or you might simply do Step 3 and see what happens.
And check my next post as I begin a new (but somewhat related) thread.
It certainly would not be reasonable to expect them to be able to reproduce and fix every single problem. Having said that, I have found that I’ve spent far more time troubleshooting small issues in DT than in any other program I routinely use. For example, this window thing: it used to work OK. Then it didn’t, so I wrote a script like then one that was posted recently to save and re-arrange the windows. Then DT started reopening the right windows again. The cycle was repeated 3-4 times, and now it’s working.
Now, obviously it is not random, so it’s a software environment issue. But I think I have had, in total, around 20 separate issues which I can only conclude are related to the software environment, of which all but 2 involved DTPO. OK, maybe it is more exposed than some other programs because eg mathematica or photoshop are closer to being complete self-contained operating systems. But it still seems more brittle than I’d have liked.
On another note, I suspect that telling users that if it’s not reproducible on a stock system then it can’t be addressed (which, mind you, isn’t what Bill said) may not be such a terrific idea. I know that DTPO has sometimes given me enough trouble and frustration that if I could get eaglefiler or something like that to do the job I’d gladly have gotten rid of it. I don’t need to be told it’s my fault for not dedicating my system to it. And also, the other two applications that had an issue with my “environment” (actually, they just didn’t like textexpander which I use to expand latex macros in all my text) ended up off my machine. I generally prefer my environment to any program in it (apart from irreplaceable ones).
EyeTV takes that honor here, with more frustrating support experiences than I’ve had with many more DTP issues.
Omitting “then it can’t be addressed” makes the statement much less contentious (to me). Informing some people “it’s not reproducible here”, regardless of conditions, is enough to ruffle their feathers.
Getting back more to the main topic …
I’ll keep posting issues/suggestions related to multi-db/window management until I’m satisfied with the outcome, whatever that may be.
Yes, whatever may be said of DT, its problems are minor and the developers responsive (apart from the fetishistic aversion to adding preferences 
--personally, I like applications like BBEdit, which has a search function to help in navigating its preferences window).
When I speculated that some issues experienced by users, that can’t be replicated on other Macs, may be due to a different software environment that comment isn’t meant to ‘put down’ the seriousness of the issue to a user.
The problem is that there are thousands of utilities that modify (i.e., hack) OS X (counting the various versions installed), and there are interactions between some utilities that are difficult to predict. For example, Textexpander and Little Snitch in combination can under some circumstances completely freeze all input to a Mac.
Earlier in this thread a user recommended running the DEVONthink application under the Guest user account, to see if the issue of window sizes and placements might be related to errors in the operating system caused by software installed in the regular user account.
Suppose everyone who experiences a particular issue could identify the installed software (or combination of software) that, when removed, no longer causes the problem. I’d guess that it would turn out not to be a single utility or combination of utilities, but different ones on different computers.
It’s bad enough at the level of the individual user, but could drive developers insane. Apple is, of course, the largest Mac developer, and their software support engineers have been pressuring the operating system developers to shut out third-party software that modifies OS X. For example, Safari without add-ons tends to be MUCH more stable than Safari with add-ons. In fact, Apple began restricting ways that one can modify OS X with Leopard, and have continued that trend in Snow Leopard.
One of the neat thing about Mac has been the tradition of third-party software that extends the capabilities of the operating system, dating back to the original Classic Mac OS. But there has been a downside to that freedom – poorly written or tested extensions. OS X has become much bigger and more complicated than the original Mac OS.
I understand the importance of utilities such as Textexpander to users. It would be a shame if such special-purpose utilities were to be locked out of OS X. I can only hope that, as OS X matures, developers will be provided bullet-proof ways to modify OS X, or enhance certain features, without creating ‘unintended consequences’ (bugs).
For example, Christian’s recent update of XMenu includes Snippets, a way of creating a menu library of snippets that can be inserted into text without hacking OS X, as most similar utilities do.
Don’t you just know it. Ages ago I worked for ROLM corp, a designer and mfr of digital PBX systems. We had the deuce of a time dealing with our independent reseller in Australia, who had a kid working in tech support who was half a whiz at the code that ran our machines. I say half because he would get into the code and hack stuff to suit certain customers’ requests and Home Base would never know it and be able to bill for the features. Half because he usually screwed up other things when doing this. One of the things this code had was a “last” statement, meaning that that was the last line of executable code. If you put in a patch in a higher-numbered address than “last,” you had to be sure to move the “last” statement or the code would never reach the patch, and of all things the kid often forgot that little thing. We constantly had to get them to express cassette tapes of the program and libraries so we could fix them, usually at no expense to the customer or the reseller.