Re: Explorer weirdness

Nebulon wrote:
[snip]

*bump* again

Couple more I remembered (because they happened again recently):

* Shift-click selection behavior is buggy. If you sort a directory and
then click one item and shift-click another the correct behavior always
occurs, but if you manually rearrange the order in which the files are
displayed (drag/drop) or drop in new files from elsewhere, or another
process creates or moves a file to the directory, this is no longer
guaranteed. Sometimes in a no-longer-sorted directory shift-clicks act
like plain clicks (they change the selection to be just the item
clicked on). Other times, they select a range, but with gaps or even
extra files selected that weren't between the start and end of range.

* Shift-arrows and shift-mousing don't always work properly, especially
if the system or specific application is sluggish. It is possible to
release the mouse button first, then shift, and have the computer
behave as though you released shift first, then the mouse button. This
obviously has catastrophic consequences for your selection. Ditto shift
and an arrow key. It seems to be a general common-controls problem,
since it afflicts nearly every Windows app. It may even be an event
dispatch bug, since it seems to affect Java with apps with lightweight
components (Swing) -- suggesting Windows is not guaranteeing that a
pair of input events actually get queued in the order they occurred,
and then processed in the order they were queued, even when the two are
handled by the same thread of the same app.

* I've occasionally managed to get directory listings with blank spaces
in them (yes, even with auto arrange on). Difficult to reproduce.

* Dragging a file from window A to window B sometimes hangs both
windows for a time; renaming a file in a window sometimes hangs that
window for a time. Occasionally, other Explorer windows hang as well,
the task bar buttons no longer function, the Start menu no longer
functions, and/or the system tray no longer responds to input as well.

This last seems to be a case of it carrying out some lengthy
calculation in the UI event handling thread instead of the separate
thread where any such calculations clearly belong. Oddly, it does so
for a single file rename or move sometimes, but only rarely without any
obvious trigger differentiating the occasions when it does from those
when it doesn't. A multiple-file move, likewise, normally generates a
dialog if it isn't done nearly instantly; but occasionally (without any
obvious correlations) there's a freeze before the dialog appears.

Explorer recovers from these in maybe 10-20 seconds, so they aren't
drastic, but they can be a nuisance.

* Alt-tab to a nonresponsive app doesn't always focus its
(nonresponsive) window. If it doesn't, a subsequent alt-tab starts at
an incorrect position in the icon sequence (not the currently focused
window, but rather the one it failed to switch to. In fact, it should
always start at far left, and on these occasions, and only these
occasions, it starts in the middle!)

With Explorer often temporarily unresponsive there's plenty of
opportunities to get tripped up by this one trying to navigate. Picture
this: you do something and Explorer hangs. You alt-tab to something
else, e.g. Web browser or Solitaire, and do something else for a bit,
then alt-tab back. Nothing happens. So you go to alt-tab to something
yet else, such as email, and it starts in the wrong place...

* Poss. related: if you just renamed one file and arrow to another and
hit F2, the insertion point doesn't always start at the far right
position. (If you didn't just rename another file first, it does always
start at the far right.)

* Drag and drop operations that encounter a problem (other than
overwrite-existing-file) simply stop. All of the files not afflicted
with the problem should move, leaving only the afflicted file(s);
instead, the first afflicted file encountered and a whole bunch of
others that it would have moved after that one all get left behind.
This behavior is inconsistent with logic and with the
overwrite-existing-file case. This also applies to mass deletes.

* Occasionally, drag and drop moves seem to generate *copies*. The
general pattern is click A, shift-click-and-start-dragging B, let go
shift, and drop at destination. In any directory with work being done
to organize its contents, sometimes a file foo.bar is copied to "copy
of foo.bar" without any explicit user action (such as, say, right
dragging foo.bar and choosing "copy" from the resulting menu).

Context menus:

* The context menu sometimes fails to appear on cue. When this occurs,
the right click has in fact instead caused the window to hang. Tabbing
away and back wakes it back up, and the menu generally appears as
expected immediately upon right-clicking a blank space again. Possibly
related, sometimes the context menu works flawlessly until you select
"new >"; then the submenu either fails to appear or appears as an empty
grey box and the window wedges. This time task switching is useless,
and the menus actually stay displayed for a while (on top of everything
else, blocking you from getting something else useful done while you
wait, of course). Eventually the menus vanish and the parent window
unfreezes. If you try the operation a second time, it invariably
succeeds flawlessly.

These seem to be a combination of a) a buggy caching algorithm and b)
doing something lengthy or that blocks on I/O in the event handling
thread.

It seems the menu items are cached somewhere, but for some stupid
reason the cache doesn't persist indefinitely. Every so often
(sometimes on successive occasions less than five minutes apart) the
cache ... disappears. Or maybe it doesn't, but Explorer thinks it did;
this would help explain the serious memory leaks mentioned earlier in
this thread. That's item a) above. Item b) is then that reloading the
cache (probably involving disk I/O) isn't done in an asynchronous
thread. Idiots!

* A similar thing happens with Start -> Programs as with context ->
New. Again, it works many times in a row, then hangs. This one is
easily the worst of the two, because the result is invariably a useless
grey box covering nearly the entire screen and preventing you from
being able to accomplish anything at all (or, at least, see wtf you're
doing) until Explorer unwedges itself.

* Selecting "new folder" from the context menu produces the behavior of
"new shortcut" instead, about one time in thirty. This one seems to be
completely random, while the previous two menu goofs seem to obey a
"seismic gap" law and occur at widely-spaced, somewhat evenly-spaced
intervals (modulo the frequency with which the potential trigger
action, e.g. right clicking in an Explorer window, occurs).

* Right clicking a blank space in a Filmstrip view window fails to give
the expected results 9 times out of 10. Only very thin regions between
two of the four thumbnails at the bottom seem to "work correctly";
other blank space produces a context menu appropriate for if you'd
right clicked on one of the file thumbnails or names or the larger
thumbnail in the top half. In particular, any right click in any white
space above the lower thumbnail row acts as if you right clicked *on*
the upper preview rather than *to one side* of it.

There's maybe 10 pixels in a Filmstrip view that you can actually right
click on to get the folder's context menu instead of one file's, if
there are four or more files. This view is almost unusable for file
organizing (rather than previewing, for which the double-click-accessed
previewer is available anyway and gives larger-resolution previews)
because only four files are shown at a time (or the total number, if
less than or equal to four). To add annoyance, changing it pretty much
necessitates a trip up to the View menu in the menu bar, because right
clicking to get the View submenu of the context menu is a crapshoot due
to the blank space bug discussed extensively in the last paragraph. The
final blow is that if a folder is changed from filmstrip view to, say,
thumbnail view (any other view, for that matter), it won't bloody STAY
that way! As detailed in the first post to this thread, it will
eventually spontaneously revert to a Filmstrip view without any user
intervention. This takes an average of less than a week for some
folders, but it varies from folder to folder and some never revert back
or only do so after weeks or even months. Frequent access seems to
reduce the risk (which is in stark contrast to most of the explorer
bugs that exhibit random tendencies; those usually show a fixed risk,
like the new folder behavior noted earlier, or become increasingly
likely to trip with frequent access and with time since the last
similar incident, like the popup menu and Start menu hangs.

The upshot of this thread is pretty clear now -- trying to organize
files on an industrial (rather than one or two files here or there)
scale in Explorer, and especially when they're photos, is a bloody
nuisance, not because the user interface contract makes it so (the way
it does with *every* photo-organizing app I've tried) but because the
user interface disobeys its contract frequently but unpredictably, the
application itself leaks memory and window handles (and when you work
with images, outright hemorrhages both), and the app is prone to
freezes and hiccups because it does tasks that potentially block on I/O
in the event-dispatch thread, computationally intensive tasks in the
event-dispatch thread, and some of the latter have poorly-scaling
algorithms: the sort seems to be O(n^2) instead of n log n, displaying
a directory in the tree view pane is sometimes O(n) in the number of
files inside the directory (even if it's not the selected one!) and
sometimes the more rational O(1) (more randomness!), and launching the
previewer on a file is O(n) in the number of files in the same
directory as the launch file (rather than the logical O(1)). If it's
caching information about the directory contents in the latter two
cases, fine, but can't it do so asynchronously?

Now I want to know three things:
1. Is there some way to work around any or all of these
bugs/hiccups/annoyances with exploder?
2. Is there at least a file management tool with image previewing
capabilities that lacks these sorts of shortcomings and is at least as
usable as Explorer would be without the bugs discussed in this thread?
3. Why have you all been ignoring this thread until now? It's been days
since the first post, without anyone other than me responding! That is
abnormal; a post seeking questions/advice/info in a high-traffic usenet
group normally gets one within hours (although it's by no means
guaranteed to be either useful or polite in my experience).

.