>Wouldn't it be easer to (try and) change the code to use this priority
>field also for normal operation ?
Possibly. I've wondered why the value is not used for this as well.
It would be disgustingly easy (which may or may not be a good thing :-)
-- we just need to change the sort routine used when the list is read
in driver, and adding priority as the primary key will only need a few
lines of code.
In other words, priority is tested first. Among entries with the same
priority, it will do what it does now (fastest estimate first).
BTW, did you know that in addition to low (0), medium (1) and high (2)
as priority keywords, you can enter a number of your own? Just another
bit of worthless trivia :-).
>1) it would change existing functionality, and so people might need to
> readjust there tapetypes/disklists
It probably would not change things very much. I doubt many people use
priority, so they most likely default to the same value and thus the
sort would not be affected. Which is a good thing.
>2) Someone needs to implement it ;)
As I said, it will be very easy to do. However, it may not already be
this way for a reason, so I'd like to hear other thoughts on it before
going ahead.
>Gerhard den Hollander Phone +31-10.280.1515
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
