n article < XXXX@XXXXX.COM >,
Ollie Clark < XXXX@XXXXX.COM > wrote:
Noted. I had a feeling it would end up here if the thread continued the
way it had been going...
It works far more responsively in a live (real-time) situation such as
the meetings in which I participate. It's just how it is, and there
really is no way I could do what I do on any other system I know.
As far as MS-Windows systems are concerned: I have worked with these for
well over a decade, and I *know* that it would be a serious handicap to
be limited by any of them. Indeed, I'd almost certainly have to return
to paper-based working.
Hmm. Hardly a conscious part of the original design concept, so that
everything fits in well with it, then... Nope, not for me. While there
are *some* facilities that can be bolted-on afterward by third party
addons, the basic handling of the user environment is not one of them.
I have tried emulating that by using Virtual-RPC's extended display
capabilities, whereby the actual display at any moment is a window of
the monitor's maximum size onto part of a "virtual screen" of the larger
size. Specifically, I set 2560 x 2048 which is exactly double the
linear capability of the portable's built-in TFT display, giving me four
times the effective screen area.
It worked OK, but needed a lot of scrolling as I went along, and was a
much more clumsy method than the standard RISC OS way.
It really is primitive, and is as out-of-date conceptually as the
original Apple Mac's one-button mouse, which they touted at the time as
being made that way "so that computer-shy executives wouldn't be able to
press the wrong mouse button, as there isn't one".
The world has moved on since those days, and users are now catching up
with much of what RISC OS users have found essential within the standard
OS. There is lots of material here for my memoirs...
Yup: works with any version of RISC OS with the later font manager, so
that's RISC OS 3 upwards, I believe.
Not a need in my situation, though I have freebie utilities to do that
in case of need. The filer action "faster" option is a boon here,
though, as I can find just about anything within a few seconds (as
indeed I did last Thursday evening at full Council, for this very
No; especially as I don't have a "My Pictures" directory. All my
pictures are stored in the place where they are relevant. For instance,
the photos of the River Admiral's Annual Inspection are stored where I
keep files relating to that kind of event (Councillor.Events , and then
by date) but pictures of my cats are kept in a suitable sub-directory of
my "Home and Family" folder.
Imagine if offices stored documents in filing cabinets the Microsoft
way: all contracts (regardless of to what they refer) in one drawer, all
letters (to everyone and about anything) in another, and so on.
In some ways; but being able to pause, accelerate and decelerate filer
actions, and even skipping "open" files during copy and move operations,
is vastly superior to the MS way. How many times have we all (I
imagine) been forced to abandon copy or move operations as soon as the
system found one of its vast number of open files?
We have very few files held in a state that prevents their copying or
moving, but when we do, we can either close them (for example, Impact
databases) and select Retry, or -- if we find that the file