Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!cam-cl!news
From: bdb@cl.cam.ac.uk (Brian Brunswick)
Newsgroups: comp.sys.acorn
Subject: Re: info server updates (sticky and largeness)
Message-ID: <1991Mar19.174113.5816@cl.cam.ac.uk>
Date: 19 Mar 91 17:41:13 GMT
References: <1991Mar15.130040.24054@newcastle.ac.uk> <5897@acorn.co.uk>
Reply-To: bdb@cl.cam.ac.uk (Brian Brunswick)
Distribution: comp
Organization: U of Cambridge Comp Lab, UK
Lines: 44

In article <5897@acorn.co.uk> pcolmer@acorn.co.uk (Philip Colmer) writes:
commenting about my !Largeness app
>
>And very nice it is too! Only a couple of gripes:

Thanks for the appreciation!
>
>* on a couple of occasions, !Largeness has wanted to move the icon bar. This
>  is not nice :-)

(Some of this is discussed in the !Help file bit about bugs - I recommend
reading that)

You are in acorn, so are probably running bits of a new riscos, which I'm
told has a pull icon bar to front feature - Was it due to this?
If someone has a foolproof way of telling that a window is the
icon bar a check can be put in - but it shows up as a standard window handle,
so if it gets in front of backdrop windows this is difficult to avoid.
Perhaps I should check for size and position, as I do for grab keys,
but this will nobble people who have changed their templates.
I would expect the same problem with !Madness.
(In general, I would expect it to move only when it shows up on the mini-view)

What happens to messages sent to the icon bar - which task do they go to,
which one is moving it, can it be discouraged from doing this?

The grab keys window for the task manager is another irritation that appears
from time to time, also. Perhaps there should be a particular task that
owns the icon bar, and gets sent messages to add icons by the wimp. This
could then use it as a grab keys window to avoid the extra window overhead
and loss of a window handle.

>
>* scrolling the iconbar becomes very difficult if you move the pointer just
>  that little bit too close to the edge of the screen

Errr... yes. I can't really see any way around that one.

Zoom box behaviour is even sadder. Try !Edit and a large file.

I'd also like a better way to do what the patch module does - perhaps in 
acorn you can exert some influence to make this sort of thing cleaner - an
omnidirectional no bounds configure bit?
Brian.Brunswick@uk.ac.cam.cl  Disclaimer.  Short sig rules!