You mean the separate viewer window, right? (Not the similar "preview pane" that is joined to the file display. Esc only closes the window not the pane, so I assume you're talking about the window but correct me if I'm wrong.)
-Nudel
I mean the separate window, yes.
(In the preview panel I view them a lot, but if I double-click them they open in Word or Firefox themselves rather than an Opus viewer window. Personally, I only really use the viewer window for pictures.)
-Nudel
See, this is where one gets a very different experience depending on the particulars of the tasks one performs. EmEditor - a fantastically configurable editor, and practically the only editor for Windows that handles *all* Unicode files correctly and reliably all the time - does not have a "replace in all open documents" feature. It's a mature product, so apparently no-one has requested it much. Myself, I need this function a few times every day, sometimes many times an hour, when working for a particular client. Sometimes "Replace in files" can substitute, other times it cannot, because I need to see and double-check the results immediately, lest I do something stupid that will corrupt the files. So I need to run another editor side-by-side, because it's missing one simple feature, while thousands of other people never notice that it's missing.
But back to the viewer...
I use TC's viewer all the time, and almost never to view pictures :) Most often I use it in conjunction with the search feature, to view all kinds of documents, usually in some dense xml-based format, to look up various things. Often there is no application associated with a filetype, or opening the file in the application would take a long time (the files can be quite large), or I'm searching for stuff in hundreds of files at a time, which no GUI text editor will handle comfortably, *or* the application associated with the files is itself slow, awkward to use and/or has a much inferior search functionality. (I'm talking about various "trade" applications used in software localization; you'd think they'd all have excellent search built in, since it's almost their whole purpose in life - I certainly thought so once :) Sometimes the associated application is designed to hide things from me, like XML tags, that I need to be able to see - a frequent case where programmers wrote software for translators seemingly without ever having consulted one.
Hmm, now I think you're talking about the preview pane since you can definitely open more than one viewer window in Opus. Select a file and use File->File Commands->Show Pictures to open the file in a viewer window. Do it to another file and you'll get a second viewer window.
Interesting. This is just what I do, and I always get a single viewer window. I assigned F3 to "View file" command. Select a file, press F3, get a separate viewer window. Without closing it, switch back to DOpus, press F3 on a different file -> the new file replaces the previous one in the same, single viewer window. (Not the internal pane.)
Another thing I've noticed:
I tried to view a PDF file. The viewer window opens empty, then Acrobat Reader opens with the document, but mostly covered by the blank viewer window.
Then I viewed an HTML file, saved from the browser. The file has a BASE HREF tag in it, so the embedded browser connects out to the site. I don't know what went wrong there, but all I got was a blank page, with no content at all, and the viewer wouldn't respond to clicking the close button for a few seconds. (I guess it was hanging there waiting for the remote server.) This is my main issue with viewers that invoke or embed handler applications instead of just showing the file contents: you get nothing if the application is unable to render the document. Try opening a badly formed XML file in IE - all you'll see is an error message. Not good. I need a viewer that will let me see the actual content, so I can still do whatever I need to do.
To view an HTML file as text you could make a button/hotkey which runs Show PLUGIN=Text
That's exactly what I need. Thanks!
(I must say DOpus has an
excellent trial policy, the best I've seen, except for infinite trials, which are mostly a thing of the past. The 60-day extension will be immensely useful, because there are plenty of things I like in DOpus and want to keep trying it out, but it does take time.)
I'm also missing the ".." entry in folder list for going up in a folder tree. Yes, I can see the up arrow above the list, but it's too tiny for fast clicking.
You could make two full-sized toolbar buttons which go up in the left and right sides if you just want a bigger target to click on. (There's already a toolbar button which goes up in the active side, of course.)
I haven't figured out yet how to make separate toolbars for the left and right lister; I'd love to have two drive bars, one for each side (it's faster than having to click a lister first, then pick a drive). It looks like you've just hinted this can be done, so I'll go digging.
This, combined with your complained above about having to push an extra arrow key to select the folder you want to enter, seems more like you're just used to exactly how TC works and want Opus to be the same, even if it doesn't make a lot of difference.
I will grant that, and still point out that I'm mostly flagging the things that slow me down. Naturally, there's a lot I have to find out about DOpus. Right now I get awed at some newly discovered feature one minute, then find things that are flying in TC, which in DOPus proceed more slowly (example: in TC dragging any file to the toolbar makes a new button, then I can right-click any button to change its icon, associated command etc.; in DOpus this doesn't seem available).
Then again, if a program has been in development for years, is at version 9+ and has a huge user base, I guess I'm not a target user. I get that a lot recently, e.g. with UltraEdit, which has like a million registered users, who apparently don't mind all the usability annoyances, big and small, I have found in 30 minutes of playing with it.
You seem to be assuming that the little things that bug you a lot are shared by everyone else?
No, that's about the opposite of what I said :) I assume I am *not* the target audience, i.e. I use the application in a weird idiomatic ways that were not in the developers' usage scenarios. I'd always like to think that developers *had* usage scenarios in the first place, though!
Joel Spolsky's "User Interface Design for Programmers" to all our favorite shareware authors, because many of them should really read those, for our benefit :)
Joel is strange for me. I seem to strongly agree with half of what he says and strongly disagree with the other half, with no middle ground. :)
Same here, and I disagree with Alan Cooper even more. But just reading a book like that makes you think about a lot of things for the first time; things you may never have considered as issues to resolve. It makes you more aware of what you're doing to people using your software.
.marek