Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Feedback wanted for a drag-and-drop install location interface for PackMan
84 views
Skip to first unread message
Tim Hill
May 18, 2013, 6:48:20 AM5/18/13
to
In article <ap.7cef70534c.a...@argonet.co.uk>, Alan
<alan...@hotmail.com> wrote:
[Snip]
> Please take a look at this and send me any feedback on it - good or
> bad. If you don't like it, alternative ideas would be greatly
> appreciated.
Fab. Just my 2p.
sp: Recommendations
q: Should it include Boot option: Run?
To be picky, and as the window has panes, will it possible to embiggen it
so as not to have to use a small scrolling pane to examine a long list or
if a line ends up being longer than the pane's width? To me, such a ten
line view onto a 100+ list may be frustrating, should it occur (on first
use?). Perusing such lists can be like having to decorate your hallway
through the letterbox.
But otherwise, tick. V.G. :-)
--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/
<alan...@hotmail.com> wrote:
[Snip]
> Please take a look at this and send me any feedback on it - good or
> bad. If you don't like it, alternative ideas would be greatly
> appreciated.
Fab. Just my 2p.
sp: Recommendations
q: Should it include Boot option: Run?
To be picky, and as the window has panes, will it possible to embiggen it
so as not to have to use a small scrolling pane to examine a long list or
if a line ends up being longer than the pane's width? To me, such a ten
line view onto a 100+ list may be frustrating, should it occur (on first
use?). Perusing such lists can be like having to decorate your hallway
through the letterbox.
But otherwise, tick. V.G. :-)
--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/
Jim Nagel
May 18, 2013, 8:37:42 AM5/18/13
to
Tim Hill wrote on 18 May:
> ... as the window has panes, will it possible to embiggen it so as not
requests, but Tim puts his finger on a pet hate of mine.
Little panes are a pain -- quite un-Acornlike in style. They are a
pain in progs like the Messenger Pro addressbook and filter-list too.
I'd suggest that any program, if it must use panes, should also
provide an easy route to the plaintext file that underlies them, which
is much easier to sort or search.
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
> ... as the window has panes, will it possible to embiggen it so as not
> to have to use a small scrolling pane to examine a long list or if a
> line ends up being longer than the pane's width? To me, such a ten
> line view onto a 100+ list may be frustrating, should it occur (on
> first use?). Perusing such lists can be like having to decorate your
> hallway through the letterbox.
I admit I haven't test-driven the prog yet as Alan_Baa (the OP)
> line ends up being longer than the pane's width? To me, such a ten
> line view onto a 100+ list may be frustrating, should it occur (on
> first use?). Perusing such lists can be like having to decorate your
> hallway through the letterbox.
requests, but Tim puts his finger on a pet hate of mine.
Little panes are a pain -- quite un-Acornlike in style. They are a
pain in progs like the Messenger Pro addressbook and filter-list too.
I'd suggest that any program, if it must use panes, should also
provide an easy route to the plaintext file that underlies them, which
is much easier to sort or search.
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
Chris Evans
May 18, 2013, 10:57:04 AM5/18/13
to
In article <534db9...@invalid.org.uk>, Tim Hill
seriously who uses it!
Why use a new word when a perfect good one exists and is understood by all:
'Enlarge'
p.s. its etymology doesn't inspire me.
> it
> so as not to have to use a small scrolling pane to examine a long list or
> if a line ends up being longer than the pane's width? To me, such a ten
> line view onto a 100+ list may be frustrating, should it occur (on first
> use?). Perusing such lists can be like having to decorate your hallway
> through the letterbox.
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
<URL:mailto:t...@invalid.org.uk> wrote:
> In article <ap.7cef70534c.a...@argonet.co.uk>, Alan
> <alan...@hotmail.com> wrote:
>
> [Snip]
>
> > Please take a look at this and send me any feedback on it - good or
> > bad. If you don't like it, alternative ideas would be greatly
> > appreciated.
>
> Fab. Just my 2p.
>
> sp: Recommendations
>
> q: Should it include Boot option: Run?
>
> To be picky, and as the window has panes, will it possible to
> embiggen
Please don't use such an ugly word. I find it very difficult to take any one
> In article <ap.7cef70534c.a...@argonet.co.uk>, Alan
> <alan...@hotmail.com> wrote:
>
> [Snip]
>
> > Please take a look at this and send me any feedback on it - good or
> > bad. If you don't like it, alternative ideas would be greatly
> > appreciated.
>
> Fab. Just my 2p.
>
> sp: Recommendations
>
> q: Should it include Boot option: Run?
>
> To be picky, and as the window has panes, will it possible to
> embiggen
seriously who uses it!
Why use a new word when a perfect good one exists and is understood by all:
'Enlarge'
p.s. its etymology doesn't inspire me.
> it
> so as not to have to use a small scrolling pane to examine a long list or
> if a line ends up being longer than the pane's width? To me, such a ten
> line view onto a 100+ list may be frustrating, should it occur (on first
> use?). Perusing such lists can be like having to decorate your hallway
> through the letterbox.
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
Vince M Hudd
May 18, 2013, 1:31:26 PM5/18/13
to
Alan <alan...@hotmail.com> wrote:
> One of the most common complaints about PackMan is that it doesn't allow
> you to specify where it installs applications.
[...]
> To this end I've create a simple test application called (TestDrag) that
> shows my ideas for implementing this.
I've now had a chance to try it out. That approach would be a (big) step in
the right direction - though it's not quite there yet.
Firstly, as others have said, use of a scrollable pane, presenting the user
with a very small area containing the dragable items (when there is more
than one), is not very nice at all. It would be better if the whole window
could be enlarged vertically. (And scrolled, of course, but it's the
enlarging that's key.)
Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps", "Run"
should be an option as well in order to complete the boot-options trinity.
Thirdly, for packages containing just one item that can be dragged, the drop
should invoke the installation - not just update the path shown in the icon
until the "Apply" button is clicked.
Finally, when there is more than one item that can be dragged, it would be
nice if there was an option to have a single drag and drop to cover all the
items in that installation - sometimes it might be desirable to put all of
the items in one destination folder, in which case multiple drag and drops
is just pointless.
When there is more than one item to drag, although it still feels "wrong",
it does make sense to wait until "Apply" is clicked, since otherwise you
could end up with incomplete installations. (Although, if there's an option
to install them with a single drag, in that case the drop should invoke the
installation as well.)
Of course, the "Look at" and "Add to Apps" - and "Run" - options need to
remain available for each item individually, so ideally you'd have a tick
box to indicate "Choose each item's destination individually" and, when it's
unticked, you have a single draggable package icon (and default path), with
each part neatly listed below it with the boot trinity options next to them)
- perhaps in the current format, but with the draggable icons and path
greyed out. And if the option is ticked, the 'package' icon is greyed out,
and the individual item icons/paths available.
If that makes sense.
But, as I said, something like your mock-up would be a step in the right
direction.
--
Soft Rock Software: http://www.softrock.co.uk
Vince M Hudd: http://misc.vinceh.com/about-vinceh/
RISCOSitory: http://www.riscository.com
> One of the most common complaints about PackMan is that it doesn't allow
> you to specify where it installs applications.
[...]
> To this end I've create a simple test application called (TestDrag) that
> shows my ideas for implementing this.
I've now had a chance to try it out. That approach would be a (big) step in
the right direction - though it's not quite there yet.
Firstly, as others have said, use of a scrollable pane, presenting the user
with a very small area containing the dragable items (when there is more
than one), is not very nice at all. It would be better if the whole window
could be enlarged vertically. (And scrolled, of course, but it's the
enlarging that's key.)
Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps", "Run"
should be an option as well in order to complete the boot-options trinity.
Thirdly, for packages containing just one item that can be dragged, the drop
should invoke the installation - not just update the path shown in the icon
until the "Apply" button is clicked.
Finally, when there is more than one item that can be dragged, it would be
nice if there was an option to have a single drag and drop to cover all the
items in that installation - sometimes it might be desirable to put all of
the items in one destination folder, in which case multiple drag and drops
is just pointless.
When there is more than one item to drag, although it still feels "wrong",
it does make sense to wait until "Apply" is clicked, since otherwise you
could end up with incomplete installations. (Although, if there's an option
to install them with a single drag, in that case the drop should invoke the
installation as well.)
Of course, the "Look at" and "Add to Apps" - and "Run" - options need to
remain available for each item individually, so ideally you'd have a tick
box to indicate "Choose each item's destination individually" and, when it's
unticked, you have a single draggable package icon (and default path), with
each part neatly listed below it with the boot trinity options next to them)
- perhaps in the current format, but with the draggable icons and path
greyed out. And if the option is ticked, the 'package' icon is greyed out,
and the individual item icons/paths available.
If that makes sense.
But, as I said, something like your mock-up would be a step in the right
direction.
--
Soft Rock Software: http://www.softrock.co.uk
Vince M Hudd: http://misc.vinceh.com/about-vinceh/
RISCOSitory: http://www.riscository.com
Tim Hill
May 19, 2013, 5:45:39 AM5/19/13
to
In article <ant18140...@client.cjemicros.co.uk>, Chris Evans
[Snip]
> > embiggen
> Please don't use such an ugly word. I find it very difficult to take
> any one seriously who uses it!
> Why use a new word when a perfect good one exists and is understood by
> all: 'Enlarge'
> p.s. its etymology doesn't inspire me.
Don't worry, Chris, your sense of humour is on order and should be with
you in the next few days.
Good grief.
[Snip]
> > embiggen
> Please don't use such an ugly word. I find it very difficult to take
> any one seriously who uses it!
> Why use a new word when a perfect good one exists and is understood by
> all: 'Enlarge'
> p.s. its etymology doesn't inspire me.
you in the next few days.
Good grief.
Alan
May 19, 2013, 12:19:46 PM5/19/13
to
On Saturday, May 18, 2013 6:31:26 PM UTC+1, Vince M Hudd wrote:
not think of enlarging the whole window until you (and others) suggested it.
I'm going to have to look at making the whole window resizable and not have
the draggable items in a separate pane.
What about the package list at the top? I'm using a scrolling list as
it's mainly a reminder of what has been selected to do so far, but
should the list of packages just be expanded into the main window.
How would I allow them to be removed from here if I did that?
> Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps", "Run"
> should be an option as well in order to complete the boot-options trinity.
>
I wasn't sure about the run option, but if you and Tim think it's useful
I'll look at that as well.
depending on if one or more items are shown and specifically didn't want it
to do this. Wouldn't it be confusing if sometime it did one thing and other
times it did something else?
type of item at the same time, do you think that is likely?
that there is a "set all locations" draggable that then just updates the
paths on screen of all the others. The user can then change individual
locations again. Or is that too confusing?
Do you think setting all the locations is a major requirement for the
first release of this new window? If not, I may leave this functionality
for later.
>
> But, as I said, something like your mock-up would be a step in the right
> direction.
Thanks, that is very encouraging.
Alan
> Alan wrote:
>
> > One of the most common complaints about PackMan is that it doesn't allow
> > you to specify where it installs applications.
>
> [...]
>
> > To this end I've create a simple test application called (TestDrag) that
> > shows my ideas for implementing this.
>
> I've now had a chance to try it out. That approach would be a (big) step in
> the right direction - though it's not quite there yet.
>
> Firstly, as others have said, use of a scrollable pane, presenting the user
> with a very small area containing the dragable items (when there is more
> than one), is not very nice at all. It would be better if the whole window
> could be enlarged vertically. (And scrolled, of course, but it's the
> enlarging that's key.)
>
Yes, I can see this now, it did look a little small to me as well, but I did
>
> > One of the most common complaints about PackMan is that it doesn't allow
> > you to specify where it installs applications.
>
> [...]
>
> > To this end I've create a simple test application called (TestDrag) that
> > shows my ideas for implementing this.
>
> I've now had a chance to try it out. That approach would be a (big) step in
> the right direction - though it's not quite there yet.
>
> Firstly, as others have said, use of a scrollable pane, presenting the user
> with a very small area containing the dragable items (when there is more
> than one), is not very nice at all. It would be better if the whole window
> could be enlarged vertically. (And scrolled, of course, but it's the
> enlarging that's key.)
>
not think of enlarging the whole window until you (and others) suggested it.
I'm going to have to look at making the whole window resizable and not have
the draggable items in a separate pane.
What about the package list at the top? I'm using a scrolling list as
it's mainly a reminder of what has been selected to do so far, but
should the list of packages just be expanded into the main window.
How would I allow them to be removed from here if I did that?
> Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps", "Run"
> should be an option as well in order to complete the boot-options trinity.
>
I'll look at that as well.
>
> Thirdly, for packages containing just one item that can be dragged, the drop
> should invoke the installation - not just update the path shown in the icon
> until the "Apply" button is clicked.
>
On an different thread I had a user who hated windows reacting differently
> Thirdly, for packages containing just one item that can be dragged, the drop
> should invoke the installation - not just update the path shown in the icon
> until the "Apply" button is clicked.
>
depending on if one or more items are shown and specifically didn't want it
to do this. Wouldn't it be confusing if sometime it did one thing and other
times it did something else?
>
> Finally, when there is more than one item that can be dragged, it would be
> nice if there was an option to have a single drag and drop to cover all the
> items in that installation - sometimes it might be desirable to put all of
> the items in one destination folder, in which case multiple drag and drops
> is just pointless.
>
I can see this would be useful if it was common to install a lot of the same
> Finally, when there is more than one item that can be dragged, it would be
> nice if there was an option to have a single drag and drop to cover all the
> items in that installation - sometimes it might be desirable to put all of
> the items in one destination folder, in which case multiple drag and drops
> is just pointless.
>
type of item at the same time, do you think that is likely?
>
>
> When there is more than one item to drag, although it still feels "wrong",
> it does make sense to wait until "Apply" is clicked, since otherwise you
> could end up with incomplete installations. (Although, if there's an option
> to install them with a single drag, in that case the drop should invoke the
> installation as well.)
>
> Of course, the "Look at" and "Add to Apps" - and "Run" - options need to
> remain available for each item individually, so ideally you'd have a tick
> box to indicate "Choose each item's destination individually" and, when it's
> unticked, you have a single draggable package icon (and default path), with
> each part neatly listed below it with the boot trinity options next to them)
> - perhaps in the current format, but with the draggable icons and path
> greyed out. And if the option is ticked, the 'package' icon is greyed out,
> and the individual item icons/paths available.
>
> If that makes sense.
It does make sense. Having read it I wonder if another approach would be
>
> When there is more than one item to drag, although it still feels "wrong",
> it does make sense to wait until "Apply" is clicked, since otherwise you
> could end up with incomplete installations. (Although, if there's an option
> to install them with a single drag, in that case the drop should invoke the
> installation as well.)
>
> Of course, the "Look at" and "Add to Apps" - and "Run" - options need to
> remain available for each item individually, so ideally you'd have a tick
> box to indicate "Choose each item's destination individually" and, when it's
> unticked, you have a single draggable package icon (and default path), with
> each part neatly listed below it with the boot trinity options next to them)
> - perhaps in the current format, but with the draggable icons and path
> greyed out. And if the option is ticked, the 'package' icon is greyed out,
> and the individual item icons/paths available.
>
> If that makes sense.
that there is a "set all locations" draggable that then just updates the
paths on screen of all the others. The user can then change individual
locations again. Or is that too confusing?
Do you think setting all the locations is a major requirement for the
first release of this new window? If not, I may leave this functionality
for later.
>
> But, as I said, something like your mock-up would be a step in the right
> direction.
Alan
Tim Hill
May 19, 2013, 12:37:41 PM5/19/13
to
In article <656b2159-eccd-4003...@googlegroups.com>, Alan
> What about the package list at the top? I'm using a scrolling list as
> it's mainly a reminder of what has been selected to do so far, but
> should the list of packages just be expanded into the main window. How
> would I allow them to be removed from here if I did that?
A tickbox against each one, so that can be de-selected?
> On an different thread I had a user who hated windows reacting
> differently depending on if one or more items are shown and
> specifically didn't want it to do this. Wouldn't it be confusing if
> sometime it did one thing and other times it did something else?
I would set it up so the initial window size is large enough to display
all the info for one package being installed - much as you have - but
enable its size to be toggled or dragged larger when the number of things
to display are too many to fit. Perhaps the appearance of a vertical
scroll bar would indicate any overflow of information.
[Snip]
T
<alan...@hotmail.com> wrote:
> On Saturday, May 18, 2013 6:31:26 PM UTC+1, Vince M Hudd wrote:
> > Alan wrote:
[Snip]
> On Saturday, May 18, 2013 6:31:26 PM UTC+1, Vince M Hudd wrote:
> > Alan wrote:
> What about the package list at the top? I'm using a scrolling list as
> it's mainly a reminder of what has been selected to do so far, but
> should the list of packages just be expanded into the main window. How
> would I allow them to be removed from here if I did that?
> On an different thread I had a user who hated windows reacting
> differently depending on if one or more items are shown and
> specifically didn't want it to do this. Wouldn't it be confusing if
> sometime it did one thing and other times it did something else?
all the info for one package being installed - much as you have - but
enable its size to be toggled or dragged larger when the number of things
to display are too many to fit. Perhaps the appearance of a vertical
scroll bar would indicate any overflow of information.
[Snip]
T
Vince M Hudd
May 20, 2013, 5:05:50 PM5/20/13
to
[the small pane with scrollbars for the "Components to configure"]
> Yes, I can see this now, it did look a little small to me as well, but I
> did not think of enlarging the whole window until you (and others)
> suggested it. I'm going to have to look at making the whole window
> resizable and not have the draggable items in a separate pane.
Top stuff!
> What about the package list at the top?
You mean the "Packages to configure" ? That doesn't bother me so much,
because (based on the test app you produced, anyway) I don't need to
interact with it - it's read only*. Also, none of the stuff in the test
contained more than a couple of lines anyway - so it's possible that in a
real case, it might be a nuisance, but at this stage I couldn't say, though
my inclination is that it wouldn't.
Thinking about it, being a small-ish area that you scroll to read, it's not
dissimilar to annoying licence prompts presented by some software
installers, where the area in which the licence text is displayed is
ridiculously small compared with the length of the licence - but I can't
imagine the contents of this box in PackMan being long enough for it to be
annoying.
* And having said that it's read-only, I note that I can select items within
it - though doing so has no effect. Is that feature there for a reason? (He
asks, before realising what you meant by the next bit...)
> I'm using a scrolling list as it's mainly a reminder of what has been
> selected to do so far, but should the list of packages just be expanded
> into the main window. How would I allow them to be removed from here if I
> did that?
Ah, okay - that would explain the "Remove from list" button, then, and the
fact that items in that window can be selected. I didn't realise that
because, here at least, it didn't seem to change even if I'd "installed" one
of the other packages - it only ever seemed to show something relevant to
the window for the current app.
That means the list could potentially become long but, still being a list
(for which there is some, albeit fairly limited, interaction), my thoughts
are as above, which is that I don't think it would be a problem - but only
in terms of its nature as a list that can be scrolled.
Now that I know what it is, I'm not sure if it makes sense as a logical
feature of the software's UI.
Surely, the list of packages that are going to be installed should be a
feature of the main list of packages window? Perhaps indicated by an icon or
some symbol or other next to each package - such as ticked for installed,
unticked for not (which IIRC one or both of PackMan and RiscPkg show -
though there should arguably be a third, to indicate something that's going
to be installed, but isn't yet). Filtering options in that window should
include packages already installed, and packages that are selected for
installation (though that's at odds with my comments about the drag and drop
saving below).
However, it *could* work, and make sense.
If the packages are listed in this window, then selecting one should also
change what's shown below, including the components to configure - and,
perhaps, the installed/to be installed filters should be available here, as
well, with the labelling differing as necessary for something already
installed - "Components to configure" becoming "Components configured" for
example.
And thinking about it further, this would therefore also be a mechanism by
which things can be reconfigured: Want to move the app somewhere else?
Another drag from here would do that - removing it from its original
location. If you didn't "Add to Apps" when you first installed it, accessing
it here would allow you to do that by just ticking the option. And so on.
The only flaw with this is selecting a simple package, with one item to drag
means the window will be one size - its smallest - and selecting one with
multiple items means changing the window to one that's bigger and can be
resized to see all the items. That really wouldn't be a nice UI feature -
which leads us back to the scrollable pane pain! :/
Perhaps, as an alternative, in the same part of the window as the pane, you
could have just one component displayed at a time (so the text might read
"Components to configure - item x of y" with up/down nudge icons suitably
placed. When the package is selected in the list at the top of the window,
item 1 is displayed. A nudge would display item 2, and so on?
It might also be nice, for packages with more than one draggable component,
if there's an option box to apply the drag location to all the other
components? Or all the remaining components - so you can drag the first to
one location, drag the second somewhere else and have that applied to the
third, fourth, and so on.
> > Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps",
> > "Run" should be an option as well in order to complete the boot-options
> > trinity.
> I wasn't sure about the run option, but if you and Tim think it's useful
> I'll look at that as well.
There's a reason I called it the boot-options trinity! :)
Before starting on this reply, I had started to doubt the worth of including
the trinity at all - when I'm installing any given app, I might not
necessarily know if I want to run it when the computer boots (or have it in
shown in Apps, or seen by the filer). It's more likely that I'd make that
decision *after* installing it and playing with it for the first time (or
after a few sessions).
However, now that you've pointed out about the list of packages in the upper
part of the window, and I've suggested an improvement to that, including the
trinity does make a lot of sense; install a package without selecting the
trinity, try it out and decide to have it seen at boot; run PackMan, pop
into this part of the program and select it here - so that PackMan knows it
was configured this way for when (if ever) it's uninstalled.
But that would only work if that list can include already installed
packages, and selecting one in the list will update the lower part of the
window accordingly.
> > Thirdly, for packages containing just one item that can be dragged, the
> > drop should invoke the installation - not just update the path shown in
> > the icon until the "Apply" button is clicked.
> On an different thread I had a user who hated windows reacting differently
> depending on if one or more items are shown and specifically didn't want
> it to do this. Wouldn't it be confusing if sometime it did one thing and
> other times it did something else?
Yes, that's a fair point - and there's also the point (which I hadn't got
before) that this is now a way to select, configure and install multiple
packages, so there's some logic to the drag updating the path rather than
initiating the install.
The problem is that dragging and dropping something, with that something not
then dropping (IYSWIM) just seems wrong. I wonder if the drop could drop
something - perhaps a pseudo-app that, when run, simply invokes PackMan,
which in turn informs the user that installation is not yet complete, with a
button to proceed with the installation.
(This could also be achieved by saving a file where the icon was dropped,
given the name of the app - but then you'd need to register a filetype, and
that would be a waste of a filetype IMO.)
> > Finally, when there is more than one item that can be dragged, it would
> > be nice if there was an option to have a single drag and drop to cover
> > all the items in that installation - sometimes it might be desirable to
> > put all of the items in one destination folder, in which case multiple
> > drag and drops is just pointless.
> I can see this would be useful if it was common to install a lot of the
> same type of item at the same time, do you think that is likely?
I've no idea - because I don't use a package manager, except for the odd
test here and there when I want to throw my opinion around, I don't know how
often packages contain multiple items that could, potentially, be installed
by drag and drop. :)
[...]
> It does make sense. Having read it I wonder if another approach would be
> that there is a "set all locations" draggable that then just updates the
> paths on screen of all the others. The user can then change individual
> locations again. Or is that too confusing?
No, I think that would work as well as the option suggested above to use the
dragged location for all remaining components.
> Do you think setting all the locations is a major requirement for the
> first release of this new window? If not, I may leave this functionality
> for later.
No, if anything it makes good sense to leave that aspect until later. You
don't want to go the whole hog and then find people don't like it - better
to do it gradually, IMO, so there's less work involved to modify the latest
feature if people are unhappy.
I might not necessarily use PackMan in anger until it's further along the
path towards what I want, but I'll endeavour to use it in order to try out
these changes along the way and offer my thoughts on them.
> Yes, I can see this now, it did look a little small to me as well, but I
> did not think of enlarging the whole window until you (and others)
> suggested it. I'm going to have to look at making the whole window
> resizable and not have the draggable items in a separate pane.
> What about the package list at the top?
because (based on the test app you produced, anyway) I don't need to
interact with it - it's read only*. Also, none of the stuff in the test
contained more than a couple of lines anyway - so it's possible that in a
real case, it might be a nuisance, but at this stage I couldn't say, though
my inclination is that it wouldn't.
Thinking about it, being a small-ish area that you scroll to read, it's not
dissimilar to annoying licence prompts presented by some software
installers, where the area in which the licence text is displayed is
ridiculously small compared with the length of the licence - but I can't
imagine the contents of this box in PackMan being long enough for it to be
annoying.
* And having said that it's read-only, I note that I can select items within
it - though doing so has no effect. Is that feature there for a reason? (He
asks, before realising what you meant by the next bit...)
> I'm using a scrolling list as it's mainly a reminder of what has been
> selected to do so far, but should the list of packages just be expanded
> into the main window. How would I allow them to be removed from here if I
> did that?
fact that items in that window can be selected. I didn't realise that
because, here at least, it didn't seem to change even if I'd "installed" one
of the other packages - it only ever seemed to show something relevant to
the window for the current app.
That means the list could potentially become long but, still being a list
(for which there is some, albeit fairly limited, interaction), my thoughts
are as above, which is that I don't think it would be a problem - but only
in terms of its nature as a list that can be scrolled.
Now that I know what it is, I'm not sure if it makes sense as a logical
feature of the software's UI.
Surely, the list of packages that are going to be installed should be a
feature of the main list of packages window? Perhaps indicated by an icon or
some symbol or other next to each package - such as ticked for installed,
unticked for not (which IIRC one or both of PackMan and RiscPkg show -
though there should arguably be a third, to indicate something that's going
to be installed, but isn't yet). Filtering options in that window should
include packages already installed, and packages that are selected for
installation (though that's at odds with my comments about the drag and drop
saving below).
However, it *could* work, and make sense.
If the packages are listed in this window, then selecting one should also
change what's shown below, including the components to configure - and,
perhaps, the installed/to be installed filters should be available here, as
well, with the labelling differing as necessary for something already
installed - "Components to configure" becoming "Components configured" for
example.
And thinking about it further, this would therefore also be a mechanism by
which things can be reconfigured: Want to move the app somewhere else?
Another drag from here would do that - removing it from its original
location. If you didn't "Add to Apps" when you first installed it, accessing
it here would allow you to do that by just ticking the option. And so on.
The only flaw with this is selecting a simple package, with one item to drag
means the window will be one size - its smallest - and selecting one with
multiple items means changing the window to one that's bigger and can be
resized to see all the items. That really wouldn't be a nice UI feature -
which leads us back to the scrollable pane pain! :/
Perhaps, as an alternative, in the same part of the window as the pane, you
could have just one component displayed at a time (so the text might read
"Components to configure - item x of y" with up/down nudge icons suitably
placed. When the package is selected in the list at the top of the window,
item 1 is displayed. A nudge would display item 2, and so on?
It might also be nice, for packages with more than one draggable component,
if there's an option box to apply the drag location to all the other
components? Or all the remaining components - so you can drag the first to
one location, drag the second somewhere else and have that applied to the
third, fourth, and so on.
> > Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps",
> > "Run" should be an option as well in order to complete the boot-options
> > trinity.
> I wasn't sure about the run option, but if you and Tim think it's useful
> I'll look at that as well.
Before starting on this reply, I had started to doubt the worth of including
the trinity at all - when I'm installing any given app, I might not
necessarily know if I want to run it when the computer boots (or have it in
shown in Apps, or seen by the filer). It's more likely that I'd make that
decision *after* installing it and playing with it for the first time (or
after a few sessions).
However, now that you've pointed out about the list of packages in the upper
part of the window, and I've suggested an improvement to that, including the
trinity does make a lot of sense; install a package without selecting the
trinity, try it out and decide to have it seen at boot; run PackMan, pop
into this part of the program and select it here - so that PackMan knows it
was configured this way for when (if ever) it's uninstalled.
But that would only work if that list can include already installed
packages, and selecting one in the list will update the lower part of the
window accordingly.
> > Thirdly, for packages containing just one item that can be dragged, the
> > drop should invoke the installation - not just update the path shown in
> > the icon until the "Apply" button is clicked.
> On an different thread I had a user who hated windows reacting differently
> depending on if one or more items are shown and specifically didn't want
> it to do this. Wouldn't it be confusing if sometime it did one thing and
> other times it did something else?
before) that this is now a way to select, configure and install multiple
packages, so there's some logic to the drag updating the path rather than
initiating the install.
The problem is that dragging and dropping something, with that something not
then dropping (IYSWIM) just seems wrong. I wonder if the drop could drop
something - perhaps a pseudo-app that, when run, simply invokes PackMan,
which in turn informs the user that installation is not yet complete, with a
button to proceed with the installation.
(This could also be achieved by saving a file where the icon was dropped,
given the name of the app - but then you'd need to register a filetype, and
that would be a waste of a filetype IMO.)
> > Finally, when there is more than one item that can be dragged, it would
> > be nice if there was an option to have a single drag and drop to cover
> > all the items in that installation - sometimes it might be desirable to
> > put all of the items in one destination folder, in which case multiple
> > drag and drops is just pointless.
> I can see this would be useful if it was common to install a lot of the
> same type of item at the same time, do you think that is likely?
test here and there when I want to throw my opinion around, I don't know how
often packages contain multiple items that could, potentially, be installed
by drag and drop. :)
[...]
> It does make sense. Having read it I wonder if another approach would be
> that there is a "set all locations" draggable that then just updates the
> paths on screen of all the others. The user can then change individual
> locations again. Or is that too confusing?
dragged location for all remaining components.
> Do you think setting all the locations is a major requirement for the
> first release of this new window? If not, I may leave this functionality
> for later.
don't want to go the whole hog and then find people don't like it - better
to do it gradually, IMO, so there's less work involved to modify the latest
feature if people are unhappy.
I might not necessarily use PackMan in anger until it's further along the
path towards what I want, but I'll endeavour to use it in order to try out
these changes along the way and offer my thoughts on them.
Chris Evans
May 21, 2013, 7:19:08 AM5/21/13
to
In article <534e37...@invalid.org.uk>, Tim Hill
<URL:mailto:t...@invalid.org.uk> wrote:
> In article <ant18140...@client.cjemicros.co.uk>, Chris Evans
> <ch...@cjemicros.co.uk> wrote:
> > In article <534db9...@invalid.org.uk>, Tim Hill
>
> [Snip]
>
> > > embiggen
>
> > Please don't use such an ugly word. I find it very difficult to take
> > any one seriously who uses it!
>
> > Why use a new word when a perfect good one exists and is understood by
> > all: 'Enlarge'
>
> > p.s. its etymology doesn't inspire me.
>
> Don't worry, Chris, your sense of humour is on order and should be with
> you in the next few days.
Don't worry it's in stock already:-)
> In article <ant18140...@client.cjemicros.co.uk>, Chris Evans
> <ch...@cjemicros.co.uk> wrote:
> > In article <534db9...@invalid.org.uk>, Tim Hill
>
> [Snip]
>
> > > embiggen
>
> > Please don't use such an ugly word. I find it very difficult to take
> > any one seriously who uses it!
>
> > Why use a new word when a perfect good one exists and is understood by
> > all: 'Enlarge'
>
> > p.s. its etymology doesn't inspire me.
>
> Don't worry, Chris, your sense of humour is on order and should be with
> you in the next few days.
Alan
May 21, 2013, 8:54:48 AM5/21/13
to
On Monday, 20 May 2013 22:05:50 UTC+1, Vince M Hudd wrote:
This test was to show what the GUI might-look like it doesn't do anything when you press the buttons.
installed and what isn't, but for PackMan I used a different idea
of showing what is going to happen in the confirmation (install/remove)
window. In PackMan it then went on to commit the changes from this
window, whereas RiscPkg you then chose a separate commit menu option.
I'm really aiming this new window at telling you what PackMan is
going to do if you apply all the changes and allow you to do some
initial configuration of the packages on install.
In the current version you just select one package and it showed
it's details and then you could either install/remove it or
close it and it forget it.
In the new window I was thinking of allowing the window to stay
open so you could add more things to it and then do them all at
once.
>
> However, it *could* work, and make sense.
>
> If the packages are listed in this window, then selecting one should also
> change what's shown below, including the components to configure - and,
> perhaps, the installed/to be installed filters should be available here, as
> well, with the labelling differing as necessary for something already
> installed - "Components to configure" becoming "Components configured" for
> example.
I only want to show what you are working with at the moment, but as you
add or remove packages from the list the Components to configure area
would have things added to it or removed from it.
>
> And thinking about it further, this would therefore also be a mechanism by
> which things can be reconfigured: Want to move the app somewhere else?
> Another drag from here would do that - removing it from its original
> location. If you didn't "Add to Apps" when you first installed it, accessing
> it here would allow you to do that by just ticking the option. And so on.
There is already an "Apps" window that shows you what's there. This allows
you to move applications etc., but should probably include a new option
to configure them as well.
>
> The only flaw with this is selecting a simple package, with one item to drag
> means the window will be one size - its smallest - and selecting one with
> multiple items means changing the window to one that's bigger and can be
> resized to see all the items. That really wouldn't be a nice UI feature -
> which leads us back to the scrollable pane pain! :/
From the various suggestions I've received, I'm thinking of now putting
everything on the new window and adding a vertical scroll bar and resize
icon. As you add items it will mean that the window's extent is resized,
but you will be able to just scroll or drag the window to show the
extra information.
>
> Perhaps, as an alternative, in the same part of the window as the pane, you
> could have just one component displayed at a time (so the text might read
> "Components to configure - item x of y" with up/down nudge icons suitably
> placed. When the package is selected in the list at the top of the window,
> item 1 is displayed. A nudge would display item 2, and so on?
I'd like to try to show everything at once if possible, but this idea does
seem a good alternative so I may revisit it if the resizable window does
not work out nicely.
>
> It might also be nice, for packages with more than one draggable component,
> if there's an option box to apply the drag location to all the other
> components? Or all the remaining components - so you can drag the first to
> one location, drag the second somewhere else and have that applied to the
> third, fourth, and so on.
I'll think about this one some more. It should work but I haven't really
figured out the one drag for all yet.
>
> > > Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps",
> > > "Run" should be an option as well in order to complete the boot-options
> > > trinity.
>
> > I wasn't sure about the run option, but if you and Tim think it's useful
> > I'll look at that as well.
>
> There's a reason I called it the boot-options trinity! :)
> Before starting on this reply, I had started to doubt the worth of including
> the trinity at all - when I'm installing any given app, I might not
> necessarily know if I want to run it when the computer boots (or have it in
> shown in Apps, or seen by the filer). It's more likely that I'd make that
> decision *after* installing it and playing with it for the first time (or
> after a few sessions).
>
> However, now that you've pointed out about the list of packages in the upper
> part of the window, and I've suggested an improvement to that, including the
> trinity does make a lot of sense; install a package without selecting the
> trinity, try it out and decide to have it seen at boot; run PackMan, pop
> into this part of the program and select it here - so that PackMan knows it
> was configured this way for when (if ever) it's uninstalled.
>
> But that would only work if that list can include already installed
> packages, and selecting one in the list will update the lower part of the
> window accordingly.
>
I think I've covered this above
> > > Thirdly, for packages containing just one item that can be dragged, the
> > > drop should invoke the installation - not just update the path shown in
> > > the icon until the "Apply" button is clicked.
>
> > On an different thread I had a user who hated windows reacting differently
> > depending on if one or more items are shown and specifically didn't want
> > it to do this. Wouldn't it be confusing if sometime it did one thing and
> > other times it did something else?
>
> Yes, that's a fair point - and there's also the point (which I hadn't got
> before) that this is now a way to select, configure and install multiple
> packages, so there's some logic to the drag updating the path rather than
> initiating the install.
>
> The problem is that dragging and dropping something, with that something not
> then dropping (IYSWIM) just seems wrong. I wonder if the drop could drop
> something - perhaps a pseudo-app that, when run, simply invokes PackMan,
> which in turn informs the user that installation is not yet complete, with a
> button to proceed with the installation.
> (This could also be achieved by saving a file where the icon was dropped,
> given the name of the app - but then you'd need to register a filetype, and
> that would be a waste of a filetype IMO.)
I think this probably over-complicates it. I'd like PackMan to do the
installation all at once and not have to come back to finish it later.
I'm glad you said this, as I'm still unsure about how best to implement
one drag for all apps. I think once the individual drags are implemented
and start to be used a better idea of what's needed should emerge.
thinking here. Thanks for trying it out and giving feedback now rather
than waiting until later.
Regards,
Alan
>
>
> That means the list could potentially become long but, still being a list
> (for which there is some, albeit fairly limited, interaction), my thoughts
> are as above, which is that I don't think it would be a problem - but only
> in terms of its nature as a list that can be scrolled.
>
> Now that I know what it is, I'm not sure if it makes sense as a logical
> feature of the software's UI.
>
> Surely, the list of packages that are going to be installed should be a
> feature of the main list of packages window? Perhaps indicated by an icon or
> some symbol or other next to each package - such as ticked for installed,
> unticked for not (which IIRC one or both of PackMan and RiscPkg show -
> though there should arguably be a third, to indicate something that's going
> to be installed, but isn't yet). Filtering options in that window should
> include packages already installed, and packages that are selected for
> installation (though that's at odds with my comments about the drag and drop
> saving below).
>
RiscPkg shows with letters in the main window what is going to be
>
> That means the list could potentially become long but, still being a list
> (for which there is some, albeit fairly limited, interaction), my thoughts
> are as above, which is that I don't think it would be a problem - but only
> in terms of its nature as a list that can be scrolled.
>
> Now that I know what it is, I'm not sure if it makes sense as a logical
> feature of the software's UI.
>
> Surely, the list of packages that are going to be installed should be a
> feature of the main list of packages window? Perhaps indicated by an icon or
> some symbol or other next to each package - such as ticked for installed,
> unticked for not (which IIRC one or both of PackMan and RiscPkg show -
> though there should arguably be a third, to indicate something that's going
> to be installed, but isn't yet). Filtering options in that window should
> include packages already installed, and packages that are selected for
> installation (though that's at odds with my comments about the drag and drop
> saving below).
>
installed and what isn't, but for PackMan I used a different idea
of showing what is going to happen in the confirmation (install/remove)
window. In PackMan it then went on to commit the changes from this
window, whereas RiscPkg you then chose a separate commit menu option.
I'm really aiming this new window at telling you what PackMan is
going to do if you apply all the changes and allow you to do some
initial configuration of the packages on install.
In the current version you just select one package and it showed
it's details and then you could either install/remove it or
close it and it forget it.
In the new window I was thinking of allowing the window to stay
open so you could add more things to it and then do them all at
once.
>
> However, it *could* work, and make sense.
>
> If the packages are listed in this window, then selecting one should also
> change what's shown below, including the components to configure - and,
> perhaps, the installed/to be installed filters should be available here, as
> well, with the labelling differing as necessary for something already
> installed - "Components to configure" becoming "Components configured" for
> example.
add or remove packages from the list the Components to configure area
would have things added to it or removed from it.
>
> And thinking about it further, this would therefore also be a mechanism by
> which things can be reconfigured: Want to move the app somewhere else?
> Another drag from here would do that - removing it from its original
> location. If you didn't "Add to Apps" when you first installed it, accessing
> it here would allow you to do that by just ticking the option. And so on.
you to move applications etc., but should probably include a new option
to configure them as well.
>
> The only flaw with this is selecting a simple package, with one item to drag
> means the window will be one size - its smallest - and selecting one with
> multiple items means changing the window to one that's bigger and can be
> resized to see all the items. That really wouldn't be a nice UI feature -
> which leads us back to the scrollable pane pain! :/
everything on the new window and adding a vertical scroll bar and resize
icon. As you add items it will mean that the window's extent is resized,
but you will be able to just scroll or drag the window to show the
extra information.
>
> Perhaps, as an alternative, in the same part of the window as the pane, you
> could have just one component displayed at a time (so the text might read
> "Components to configure - item x of y" with up/down nudge icons suitably
> placed. When the package is selected in the list at the top of the window,
> item 1 is displayed. A nudge would display item 2, and so on?
seem a good alternative so I may revisit it if the resizable window does
not work out nicely.
>
> It might also be nice, for packages with more than one draggable component,
> if there's an option box to apply the drag location to all the other
> components? Or all the remaining components - so you can drag the first to
> one location, drag the second somewhere else and have that applied to the
> third, fourth, and so on.
figured out the one drag for all yet.
>
> > > Secondly, as Tim pointed out, as well as "Look at" and "Add to Apps",
> > > "Run" should be an option as well in order to complete the boot-options
> > > trinity.
>
> > I wasn't sure about the run option, but if you and Tim think it's useful
> > I'll look at that as well.
>
> There's a reason I called it the boot-options trinity! :)
> Before starting on this reply, I had started to doubt the worth of including
> the trinity at all - when I'm installing any given app, I might not
> necessarily know if I want to run it when the computer boots (or have it in
> shown in Apps, or seen by the filer). It's more likely that I'd make that
> decision *after* installing it and playing with it for the first time (or
> after a few sessions).
>
> However, now that you've pointed out about the list of packages in the upper
> part of the window, and I've suggested an improvement to that, including the
> trinity does make a lot of sense; install a package without selecting the
> trinity, try it out and decide to have it seen at boot; run PackMan, pop
> into this part of the program and select it here - so that PackMan knows it
> was configured this way for when (if ever) it's uninstalled.
>
> But that would only work if that list can include already installed
> packages, and selecting one in the list will update the lower part of the
> window accordingly.
>
> > > Thirdly, for packages containing just one item that can be dragged, the
> > > drop should invoke the installation - not just update the path shown in
> > > the icon until the "Apply" button is clicked.
>
> > On an different thread I had a user who hated windows reacting differently
> > depending on if one or more items are shown and specifically didn't want
> > it to do this. Wouldn't it be confusing if sometime it did one thing and
> > other times it did something else?
>
> Yes, that's a fair point - and there's also the point (which I hadn't got
> before) that this is now a way to select, configure and install multiple
> packages, so there's some logic to the drag updating the path rather than
> initiating the install.
>
> The problem is that dragging and dropping something, with that something not
> then dropping (IYSWIM) just seems wrong. I wonder if the drop could drop
> something - perhaps a pseudo-app that, when run, simply invokes PackMan,
> which in turn informs the user that installation is not yet complete, with a
> button to proceed with the installation.
> (This could also be achieved by saving a file where the icon was dropped,
> given the name of the app - but then you'd need to register a filetype, and
> that would be a waste of a filetype IMO.)
installation all at once and not have to come back to finish it later.
one drag for all apps. I think once the individual drags are implemented
and start to be used a better idea of what's needed should emerge.
>
>
> I might not necessarily use PackMan in anger until it's further along the
> path towards what I want, but I'll endeavour to use it in order to try out
> these changes along the way and offer my thoughts on them.
>
A very reasonable attitude. I suspect there are others who share your
>
> I might not necessarily use PackMan in anger until it's further along the
> path towards what I want, but I'll endeavour to use it in order to try out
> these changes along the way and offer my thoughts on them.
>
thinking here. Thanks for trying it out and giving feedback now rather
than waiting until later.
Regards,
Alan
John Rickman Iyonix
May 21, 2013, 9:02:01 AM5/21/13
to
Chris Evans wrote
> In article <534e37...@invalid.org.uk>, Tim Hill
> <URL:mailto:t...@invalid.org.uk> wrote:
>> In article <ant18140...@client.cjemicros.co.uk>, Chris Evans
>> <ch...@cjemicros.co.uk> wrote:
>>> In article <534db9...@invalid.org.uk>, Tim Hill
>>
>> [Snip]
>>
>>>> embiggen
>>
>>> Please don't use such an ugly word. I find it very difficult to take
>>> any one seriously who uses it!
>>
>>> Why use a new word when a perfect good one exists and is understood by
>>> all: 'Enlarge'
>>
>>> p.s. its etymology doesn't inspire me.
>>
>> Don't worry, Chris, your sense of humour is on order and should be with
>> you in the next few days.
> Don't worry it's in stock already:-)
I took it to be a play on embolden, which in the context of fonts is
amusing.
John
--
> In article <534e37...@invalid.org.uk>, Tim Hill
> <URL:mailto:t...@invalid.org.uk> wrote:
>> In article <ant18140...@client.cjemicros.co.uk>, Chris Evans
>> <ch...@cjemicros.co.uk> wrote:
>>> In article <534db9...@invalid.org.uk>, Tim Hill
>>
>> [Snip]
>>
>>>> embiggen
>>
>>> Please don't use such an ugly word. I find it very difficult to take
>>> any one seriously who uses it!
>>
>>> Why use a new word when a perfect good one exists and is understood by
>>> all: 'Enlarge'
>>
>>> p.s. its etymology doesn't inspire me.
>>
>> Don't worry, Chris, your sense of humour is on order and should be with
>> you in the next few days.
> Don't worry it's in stock already:-)
amusing.
John
--
Vince M Hudd
May 23, 2013, 1:39:28 PM5/23/13
to
[...]
> > Ah, okay - that would explain the "Remove from list" button, then, and
> > the fact that items in that window can be selected. I didn't realise
> > that because, here at least, it didn't seem to change even if I'd
> > "installed" one of the other packages - it only ever seemed to show
> > something relevant to the window for the current app.
> This test was to show what the GUI might-look like it doesn't do anything
> when you press the buttons.
I see.
Unfortunately, a combination of that button not doing anything, and the list
not containing all the packages that would be installed - albeit from the
four examples - is why it wasn't obvious to me how those aspects of the GUI
fit together. :)
[snip showing status - installed, to be installed, etc - in the main list
window]
> I'm really aiming this new window at telling you what PackMan is going to
> do if you apply all the changes and allow you to do some initial
> configuration of the packages on install.
Ah, okay - I'm starting to understand better now. That list is *purely* what
is going to be installed *this session*. Once the packages listed there are
installed, that list will be empty again.
[...]
> > And thinking about it further, this would therefore also be a mechanism
> > by which things can be reconfigured: Want to move the app somewhere
> > else? Another drag from here would do that - removing it from its
> > original location. If you didn't "Add to Apps" when you first installed
> > it, accessing it here would allow you to do that by just ticking the
> > option. And so on.
> There is already an "Apps" window that shows you what's there. This allows
> you to move applications etc., but should probably include a new option to
> configure them as well.
ISTR that coming up in a recent discussion - I can't remember if it was
pointed out to me, or I found it while playing, but I do remember thinking
that while I was glad there was now a way to move things, I wasn't too
impressed with how it's done. I probably said something to that effect.
[...]
> > Perhaps, as an alternative, in the same part of the window as the pane,
> > you could have just one component displayed at a time (so the text might
> > read "Components to configure - item x of y" with up/down nudge icons
> > suitably placed. When the package is selected in the list at the top of
> > the window, item 1 is displayed. A nudge would display item 2, and so
> > on?
> I'd like to try to show everything at once if possible, but this idea does
> seem a good alternative so I may revisit it if the resizable window does
> not work out nicely.
Actually, I was talking out of the wrong hole when I dissed the idea of
expanding the window and suggested that alternative. I was envisioning a
window of fixed size which had no scroll bars or drag tool suddenly gaining
them when a different package was selected (with multiple drags) and losing
them again when a single-drag package was selected - which really would be
horrid. But if the window has the controls the whole time, and its just the
extent that changes (and the size of the scroll bar accordingly) then that's
not a problem at all.
[...]
> > The problem is that dragging and dropping something, with that something
> > not then dropping (IYSWIM) just seems wrong. I wonder if the drop could
> > drop something - perhaps a pseudo-app that, when run, simply invokes
> > PackMan, which in turn informs the user that installation is not yet
> > complete, with a button to proceed with the installation. (This could
> > also be achieved by saving a file where the icon was dropped, given the
> > name of the app - but then you'd need to register a filetype, and that
> > would be a waste of a filetype IMO.)
> I think this probably over-complicates it. I'd like PackMan to do the
> installation all at once and not have to come back to finish it later.
Which means we're back to drags with no drop - and that strikes me as a
horrible thing to have in a drag and drop environment.
IMO, this is something that really should be in the Style Guide in big,
capital, shouty letters. Something along the lines of:
---8<----
When a location is being set for something by drag and drop, if the location
is set by dragging from the configuration tool and dropping into a folder,
something should appear in that folder as a direct result of that drop.
If, on the other hand, the configuration tool requires a location, but isn't
going to place something there immediately, then the drag and drop should be
the other way around: the destination folder should be dragged, and dropped
onto the configuration tool.
The window which is updated should be the one that is the target of the
drop.
----8<----
Preferably with the word "must" where I've used "should" (which I used
because I'm voicing my opinion).
> > Ah, okay - that would explain the "Remove from list" button, then, and
> > the fact that items in that window can be selected. I didn't realise
> > that because, here at least, it didn't seem to change even if I'd
> > "installed" one of the other packages - it only ever seemed to show
> > something relevant to the window for the current app.
> This test was to show what the GUI might-look like it doesn't do anything
> when you press the buttons.
Unfortunately, a combination of that button not doing anything, and the list
not containing all the packages that would be installed - albeit from the
four examples - is why it wasn't obvious to me how those aspects of the GUI
fit together. :)
[snip showing status - installed, to be installed, etc - in the main list
window]
> I'm really aiming this new window at telling you what PackMan is going to
> do if you apply all the changes and allow you to do some initial
> configuration of the packages on install.
is going to be installed *this session*. Once the packages listed there are
installed, that list will be empty again.
[...]
> > And thinking about it further, this would therefore also be a mechanism
> > by which things can be reconfigured: Want to move the app somewhere
> > else? Another drag from here would do that - removing it from its
> > original location. If you didn't "Add to Apps" when you first installed
> > it, accessing it here would allow you to do that by just ticking the
> > option. And so on.
> There is already an "Apps" window that shows you what's there. This allows
> you to move applications etc., but should probably include a new option to
> configure them as well.
pointed out to me, or I found it while playing, but I do remember thinking
that while I was glad there was now a way to move things, I wasn't too
impressed with how it's done. I probably said something to that effect.
[...]
> > Perhaps, as an alternative, in the same part of the window as the pane,
> > you could have just one component displayed at a time (so the text might
> > read "Components to configure - item x of y" with up/down nudge icons
> > suitably placed. When the package is selected in the list at the top of
> > the window, item 1 is displayed. A nudge would display item 2, and so
> > on?
> I'd like to try to show everything at once if possible, but this idea does
> seem a good alternative so I may revisit it if the resizable window does
> not work out nicely.
expanding the window and suggested that alternative. I was envisioning a
window of fixed size which had no scroll bars or drag tool suddenly gaining
them when a different package was selected (with multiple drags) and losing
them again when a single-drag package was selected - which really would be
horrid. But if the window has the controls the whole time, and its just the
extent that changes (and the size of the scroll bar accordingly) then that's
not a problem at all.
[...]
> > The problem is that dragging and dropping something, with that something
> > not then dropping (IYSWIM) just seems wrong. I wonder if the drop could
> > drop something - perhaps a pseudo-app that, when run, simply invokes
> > PackMan, which in turn informs the user that installation is not yet
> > complete, with a button to proceed with the installation. (This could
> > also be achieved by saving a file where the icon was dropped, given the
> > name of the app - but then you'd need to register a filetype, and that
> > would be a waste of a filetype IMO.)
> I think this probably over-complicates it. I'd like PackMan to do the
> installation all at once and not have to come back to finish it later.
horrible thing to have in a drag and drop environment.
IMO, this is something that really should be in the Style Guide in big,
capital, shouty letters. Something along the lines of:
---8<----
When a location is being set for something by drag and drop, if the location
is set by dragging from the configuration tool and dropping into a folder,
something should appear in that folder as a direct result of that drop.
If, on the other hand, the configuration tool requires a location, but isn't
going to place something there immediately, then the drag and drop should be
the other way around: the destination folder should be dragged, and dropped
onto the configuration tool.
The window which is updated should be the one that is the target of the
drop.
----8<----
Preferably with the word "must" where I've used "should" (which I used
because I'm voicing my opinion).
Vince M Hudd
May 23, 2013, 1:55:56 PM5/23/13
to
Vince M Hudd <vin...@softrock.co.uk> wrote:
> Alan <alan...@hotmail.com> wrote:
[...]
> When a location is being set for something by drag and drop, if
> the location is set by dragging from the configuration tool and dropping
> into a folder, something should appear in that folder as a direct result
> of that drop.
>
> If, on the other hand, the configuration tool requires a location, but
> isn't going to place something there immediately, then the drag and drop
> should be the other way around: the destination folder should be dragged,
> and dropped onto the configuration tool.
>
> The window which is updated should be the one that is the target of the
> drop.
And actually, that's your solution, right there.
Instead of dragging from the package window to a folder, allow a folder to
be dragged to the window in order to set the location. This seems odd for
installing software, but if the drop isn't going to have an immediate
effect, then it's the right way to do it - and has an advantage when it
comes to a package manager, through which a user might be installing lots of
packages.
Chiefly, that if said user's installed applications are all in
subdirectories of Foo (such as Foo.Graphics, Foo.Games, etc) then it'll be
more convenient to just open Foo, and drag the Graphics folder onto the path
icon for a graphics package, the Games folder onto the path icon for a game,
etc., than it would be to *open* Graphics, and drag the app's icon to the
folder, *open* games, and drag the game's icon to the folder... and so on.
> Alan <alan...@hotmail.com> wrote:
[...]
> When a location is being set for something by drag and drop, if
> the location is set by dragging from the configuration tool and dropping
> into a folder, something should appear in that folder as a direct result
> of that drop.
>
> If, on the other hand, the configuration tool requires a location, but
> isn't going to place something there immediately, then the drag and drop
> should be the other way around: the destination folder should be dragged,
> and dropped onto the configuration tool.
>
> The window which is updated should be the one that is the target of the
> drop.
Instead of dragging from the package window to a folder, allow a folder to
be dragged to the window in order to set the location. This seems odd for
installing software, but if the drop isn't going to have an immediate
effect, then it's the right way to do it - and has an advantage when it
comes to a package manager, through which a user might be installing lots of
packages.
Chiefly, that if said user's installed applications are all in
subdirectories of Foo (such as Foo.Graphics, Foo.Games, etc) then it'll be
more convenient to just open Foo, and drag the Graphics folder onto the path
icon for a graphics package, the Games folder onto the path icon for a game,
etc., than it would be to *open* Graphics, and drag the app's icon to the
folder, *open* games, and drag the game's icon to the folder... and so on.
Martin Bazley
May 23, 2013, 2:27:33 PM5/23/13
to
The following bytes were arranged on 23 May 2013 by Vince M Hudd :
> Chiefly, that if said user's installed applications are all in
> subdirectories of Foo (such as Foo.Graphics, Foo.Games, etc) then it'll be
> more convenient to just open Foo, and drag the Graphics folder onto the path
> icon for a graphics package, the Games folder onto the path icon for a game,
> etc., than it would be to *open* Graphics, and drag the app's icon to the
> folder, *open* games, and drag the game's icon to the folder... and so on.
Unfortunately, this type of user interface design has one major drawback
which its proponents have never adequately answered: what happens if you
want to install to the root of a disc? What do you drag then?
There's a reason the whole drag-a-directory-icon-to-a-Filer-window thing
became common practice.
Your philosophy works fine and is logical for files, which is all most
applications will ever deal in, but unfortunately the root directory is
still a directory. And personally, in this case I think I'd still find
the concept of dragging the items I wish to 'save' into the directory
window which I wish to 'save' them into more intuitive.
The reason I haven't posted in this thread yet is that it was
monumentally badly scheduled, in a week when I had no fewer than three
exams to sit in quick succession. But term's just finished now, so
maybe I'll have some proper opinions later on.
One immediate thought which occurs to me, although I haven't really
looked at your proposal yet so don't know how relevant it'll be,
concerns the setting of default locations. I really would rather have
these be a last-resort thing, because if the filename fields were
already populated with the default locations when the window opened, and
I had a lot of icons to drag, I'd find it difficult to keep track of
which boxes I had already manually updated. I want them blank until
the point of installation, or at least initially differently coloured to
make it plain that the location hasn't been changed from the package's
default.
--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
\_> <_/ ======================= Martin Bazley ==========================
> Chiefly, that if said user's installed applications are all in
> subdirectories of Foo (such as Foo.Graphics, Foo.Games, etc) then it'll be
> more convenient to just open Foo, and drag the Graphics folder onto the path
> icon for a graphics package, the Games folder onto the path icon for a game,
> etc., than it would be to *open* Graphics, and drag the app's icon to the
> folder, *open* games, and drag the game's icon to the folder... and so on.
which its proponents have never adequately answered: what happens if you
want to install to the root of a disc? What do you drag then?
There's a reason the whole drag-a-directory-icon-to-a-Filer-window thing
became common practice.
Your philosophy works fine and is logical for files, which is all most
applications will ever deal in, but unfortunately the root directory is
still a directory. And personally, in this case I think I'd still find
the concept of dragging the items I wish to 'save' into the directory
window which I wish to 'save' them into more intuitive.
The reason I haven't posted in this thread yet is that it was
monumentally badly scheduled, in a week when I had no fewer than three
exams to sit in quick succession. But term's just finished now, so
maybe I'll have some proper opinions later on.
One immediate thought which occurs to me, although I haven't really
looked at your proposal yet so don't know how relevant it'll be,
concerns the setting of default locations. I really would rather have
these be a last-resort thing, because if the filename fields were
already populated with the default locations when the window opened, and
I had a lot of icons to drag, I'd find it difficult to keep track of
which boxes I had already manually updated. I want them blank until
the point of installation, or at least initially differently coloured to
make it plain that the location hasn't been changed from the package's
default.
--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
\_> <_/ ======================= Martin Bazley ==========================
Vince M Hudd
May 24, 2013, 6:03:03 AM5/24/13
to
Martin Bazley <martin...@blueyonder.co.uk> wrote:
> The following bytes were arranged on 23 May 2013 by Vince M Hudd :
[Drag and drop should drop something. Therefore dragging and dropping from
> The following bytes were arranged on 23 May 2013 by Vince M Hudd :
an installer/package manager should result in something appearing in the
destination, or - if the installer just wants to update the path - the drag
should be a folder *onto* the installer]
> Unfortunately, this type of user interface design has one major drawback
> which its proponents have never adequately answered: what happens if you
> want to install to the root of a disc? What do you drag then?
You'll end up with the path saying something like:
ADFS::Foo.$.Whatever
You could then do something crazy, like click in that path and delete
".whatever"
Hey presto, the installation path is now the root.
Although, TBH, I don't think anyone should ever be installing things in the
root directory - this is something that should be strongly discouraged,
though not forbidden, because the bottom line is that it's the user's own
computer (so the extra step of having to delete the ".whatever" is, IMO, not
a bad thing).
[...]
> And personally, in this case I think I'd still find the concept of
> dragging the items I wish to 'save' into the directory window which I wish
> to 'save' them into more intuitive.
also includes the word "intuitive" - unless there's a "counter-" immediately
in front of it.
That's why, prior to suggesting dragging the destination folder onto the
package manager's path, I suggested dropping a dummy application. Then a
drag and drop from the package manager to the destination would make sense.
[...]
> One immediate thought which occurs to me, although I haven't really looked
> at your proposal yet so don't know how relevant it'll be, concerns the
> setting of default locations. I really would rather have these be a
> last-resort thing, because if the filename fields were already populated
> with the default locations when the window opened, and I had a lot of
> icons to drag, I'd find it difficult to keep track of which boxes I had
> already manually updated. I want them blank until the point of
> installation, or at least initially differently coloured to make it plain
> that the location hasn't been changed from the package's default.
Alan
May 24, 2013, 8:09:32 AM5/24/13
to
On Friday, 24 May 2013 11:03:03 UTC+1, Vince M Hudd wrote:
directory but when you do having to take extra steps using the keyboard
doesn't seem quite right.
>
> [...]
>
> > And personally, in this case I think I'd still find the concept of
> > dragging the items I wish to 'save' into the directory window which I wish
> > to 'save' them into more intuitive.
>
> A drag and drop that doesn't drop does not, IMO, belong in a sentence that
> also includes the word "intuitive" - unless there's a "counter-" immediately
> in front of it.
>
I do see your point here, but it does seem more natural to me to drag the
item to where you want it to go. The problem is when there are multiple
items that can be dragged to multiple places.
As the majority of installs will just involve one drag, I've been
toying with the idea of an option button at the bottom of the screen
which is automatically enabled when there is only one item to drag
which says something line "install on drop", or maybe a message
instead.
> > One immediate thought which occurs to me, although I haven't really looked
> > at your proposal yet so don't know how relevant it'll be, concerns the
> > setting of default locations. I really would rather have these be a
> > last-resort thing, because if the filename fields were already populated
> > with the default locations when the window opened, and I had a lot of
> > icons to drag, I'd find it difficult to keep track of which boxes I had
> > already manually updated. I want them blank until the point of
> > installation, or at least initially differently coloured to make it plain
> > that the location hasn't been changed from the package's default.
>
> Good point, yes.
I'm not convinced this is needed, surely you can see where everything
is going at all times anyway, but a different colour may be the way
to go if it is needed.
From you earlier post:
multiple items can be added to the window so it can be seen how the window
appears in these cases.
> > > There is already an "Apps" window that shows you what's there. This allows
> > > you to move applications etc., but should probably include a new option to
> > > configure them as well.
> ISTR that coming up in a recent discussion - I can't remember if it was
> pointed out to me, or I found it while playing, but I do remember thinking
> that while I was glad there was now a way to move things, I wasn't too
> impressed with how it's done. I probably said something to that effect.
I can't really remember this discussion either, but I'm not sure what you
didn't like about it. Was it just that it took a while to find it? It all
works with RISC OS menus and drag-and-drop, so I'm unsure what there was
to dislike.
Regards,
Alan
> Martin Bazley wrote:
>
> > The following bytes were arranged on 23 May 2013 by Vince M Hudd :
>
> [Drag and drop should drop something. Therefore dragging and dropping from
> an installer/package manager should result in something appearing in the
> destination, or - if the installer just wants to update the path - the drag
> should be a folder *onto* the installer]
>
> > Unfortunately, this type of user interface design has one major drawback
> > which its proponents have never adequately answered: what happens if you
> > want to install to the root of a disc? What do you drag then?
>
> Easy: A folder in that root.
>
> You'll end up with the path saying something like:
> ADFS::Foo.$.Whatever
>
> You could then do something crazy, like click in that path and delete
> ".whatever"
>
> Hey presto, the installation path is now the root.
>
> Although, TBH, I don't think anyone should ever be installing things in the
> root directory - this is something that should be strongly discouraged,
> though not forbidden, because the bottom line is that it's the user's own
> computer (so the extra step of having to delete the ".whatever" is, IMO, not
> a bad thing).
I'm not sure on this, I agree you don't want much if anything in your root
>
> > The following bytes were arranged on 23 May 2013 by Vince M Hudd :
>
> [Drag and drop should drop something. Therefore dragging and dropping from
> an installer/package manager should result in something appearing in the
> destination, or - if the installer just wants to update the path - the drag
> should be a folder *onto* the installer]
>
> > Unfortunately, this type of user interface design has one major drawback
> > which its proponents have never adequately answered: what happens if you
> > want to install to the root of a disc? What do you drag then?
>
> Easy: A folder in that root.
>
> You'll end up with the path saying something like:
> ADFS::Foo.$.Whatever
>
> You could then do something crazy, like click in that path and delete
> ".whatever"
>
> Hey presto, the installation path is now the root.
>
> Although, TBH, I don't think anyone should ever be installing things in the
> root directory - this is something that should be strongly discouraged,
> though not forbidden, because the bottom line is that it's the user's own
> computer (so the extra step of having to delete the ".whatever" is, IMO, not
> a bad thing).
directory but when you do having to take extra steps using the keyboard
doesn't seem quite right.
>
> [...]
>
> > And personally, in this case I think I'd still find the concept of
> > dragging the items I wish to 'save' into the directory window which I wish
> > to 'save' them into more intuitive.
>
> A drag and drop that doesn't drop does not, IMO, belong in a sentence that
> also includes the word "intuitive" - unless there's a "counter-" immediately
> in front of it.
>
item to where you want it to go. The problem is when there are multiple
items that can be dragged to multiple places.
As the majority of installs will just involve one drag, I've been
toying with the idea of an option button at the bottom of the screen
which is automatically enabled when there is only one item to drag
which says something line "install on drop", or maybe a message
instead.
> > One immediate thought which occurs to me, although I haven't really looked
> > at your proposal yet so don't know how relevant it'll be, concerns the
> > setting of default locations. I really would rather have these be a
> > last-resort thing, because if the filename fields were already populated
> > with the default locations when the window opened, and I had a lot of
> > icons to drag, I'd find it difficult to keep track of which boxes I had
> > already manually updated. I want them blank until the point of
> > installation, or at least initially differently coloured to make it plain
> > that the location hasn't been changed from the package's default.
>
> Good point, yes.
is going at all times anyway, but a different colour may be the way
to go if it is needed.
From you earlier post:
> > > This test was to show what the GUI might-look like it doesn't do anything
> > > when you press the buttons.
> I see.
> Unfortunately, a combination of that button not doing anything, and the list
> not containing all the packages that would be installed - albeit from the
> four examples - is why it wasn't obvious to me how those aspects of the GUI
> fit together. :)
I'll try to add a bit more "fake" functionality to the next test so that
> > > when you press the buttons.
> I see.
> Unfortunately, a combination of that button not doing anything, and the list
> not containing all the packages that would be installed - albeit from the
> four examples - is why it wasn't obvious to me how those aspects of the GUI
> fit together. :)
multiple items can be added to the window so it can be seen how the window
appears in these cases.
> > > There is already an "Apps" window that shows you what's there. This allows
> > > you to move applications etc., but should probably include a new option to
> > > configure them as well.
> ISTR that coming up in a recent discussion - I can't remember if it was
> pointed out to me, or I found it while playing, but I do remember thinking
> that while I was glad there was now a way to move things, I wasn't too
> impressed with how it's done. I probably said something to that effect.
didn't like about it. Was it just that it took a while to find it? It all
works with RISC OS menus and drag-and-drop, so I'm unsure what there was
to dislike.
Regards,
Alan
spampling
May 25, 2013, 2:57:15 AM5/25/13
to
In article <9615595f-d4f3-401d...@googlegroups.com>, Alan
work that dump a GB or so of files (literally thousands) into C:\ - then
complain they can't find things or complain that the machine is slow when
they have thumbnail view on.
It's the equivalent of filing all your paperwork in a big pile on the
floor.
BTW the suggestion Vince makes of dragging a folder to the installer
strikes me as the reverse of the operation that will take place and is most
definitely counter-intuitive
--
Steve Pampling
<alan...@hotmail.com> wrote:
> I'm not sure on this, I agree you don't want much if anything in your
> root directory but when you do having to take extra steps using the
> keyboard doesn't seem quite right.
That would be the reasoning used by large numbers of managerial types at
> I'm not sure on this, I agree you don't want much if anything in your
> root directory but when you do having to take extra steps using the
> keyboard doesn't seem quite right.
work that dump a GB or so of files (literally thousands) into C:\ - then
complain they can't find things or complain that the machine is slow when
they have thumbnail view on.
It's the equivalent of filing all your paperwork in a big pile on the
floor.
BTW the suggestion Vince makes of dragging a folder to the installer
strikes me as the reverse of the operation that will take place and is most
definitely counter-intuitive
--
Steve Pampling
Tim Hill
May 25, 2013, 5:35:02 AM5/25/13
to
In article <53513f3961...@btinternet.com>, spampling
> BTW the suggestion Vince makes of dragging a folder to the installer
> strikes me as the reverse of the operation that will take place and is
> most definitely counter-intuitive
Unless, in big friendly letters, it says to do that as an OPTION.
IMO The only two standard apps in Root ought to be !Boot and !Disknight,
setting aside my own: !Files, !Tools, and !To do :-)
<spam....@btinternet.com> wrote:
> In article <9615595f-d4f3-401d...@googlegroups.com>,
> Alan <alan...@hotmail.com> wrote:
> > I'm not sure on this, I agree you don't want much if anything in your
> > root directory but when you do having to take extra steps using the
> > keyboard doesn't seem quite right.
> That would be the reasoning used by large numbers of managerial types
> at work that dump a GB or so of files (literally thousands) into C:\ -
> then complain they can't find things or complain that the machine is
> slow when they have thumbnail view on.
> It's the equivalent of filing all your paperwork in a big pile on the
> floor.
Those same people do that too, IME.
> In article <9615595f-d4f3-401d...@googlegroups.com>,
> Alan <alan...@hotmail.com> wrote:
> > I'm not sure on this, I agree you don't want much if anything in your
> > root directory but when you do having to take extra steps using the
> > keyboard doesn't seem quite right.
> That would be the reasoning used by large numbers of managerial types
> at work that dump a GB or so of files (literally thousands) into C:\ -
> then complain they can't find things or complain that the machine is
> slow when they have thumbnail view on.
> It's the equivalent of filing all your paperwork in a big pile on the
> floor.
> BTW the suggestion Vince makes of dragging a folder to the installer
> strikes me as the reverse of the operation that will take place and is
> most definitely counter-intuitive
IMO The only two standard apps in Root ought to be !Boot and !Disknight,
setting aside my own: !Files, !Tools, and !To do :-)
Chris Johnson
May 25, 2013, 5:24:15 AM5/25/13
to
> BTW the suggestion Vince makes of dragging a folder to the
> installer strikes me as the reverse of the operation that will take
> place and is most definitely counter-intuitive
In a couple of my recent apps where paths have to be set up, I
> installer strikes me as the reverse of the operation that will take
> place and is most definitely counter-intuitive
decided to provide both options. This was after seeing some similar
comments in a mail list (or newsgroup) and because not all apps do
the same. You can either drag a dir icon into the destination
directory, or drag the destination dir into the appropriate writable
field in the app. I actually think I prefer the former, but each to
his own. Now that will really muddy the waters.
--
Chris Johnson
Vince M Hudd
May 25, 2013, 6:34:10 AM5/25/13
to
Alan <alan...@hotmail.com> wrote:
> On Friday, 24 May 2013 11:03:03 UTC+1, Vince M Hudd wrote:
> > Although, TBH, I don't think anyone should ever be installing things in
> > the root directory - this is something that should be strongly
> > discouraged, though not forbidden, because the bottom line is that it's
> > the user's own computer (so the extra step of having to delete the
> > ".whatever" is, IMO, not a bad thing).
> I'm not sure on this, I agree you don't want much if anything in your root
> directory but when you do having to take extra steps using the keyboard
> doesn't seem quite right.
I don't think anyone should ever be *installing* things in the root
> On Friday, 24 May 2013 11:03:03 UTC+1, Vince M Hudd wrote:
> > Although, TBH, I don't think anyone should ever be installing things in
> > the root directory - this is something that should be strongly
> > discouraged, though not forbidden, because the bottom line is that it's
> > the user's own computer (so the extra step of having to delete the
> > ".whatever" is, IMO, not a bad thing).
> I'm not sure on this, I agree you don't want much if anything in your root
> directory but when you do having to take extra steps using the keyboard
> doesn't seem quite right.
directory.
There are things which can, perfectly reasonably, be placed there, such as
directories, but I don't think anything should ever be *installed* there.
The only application directory that ought to be in root is !Boot - which
isn't supplied by the package manager (and if it was, it'd be a special case
anyway).
Therefore the extra steps using the keyboard *are a way to discourage
people* from doing something they shouldn't.
They still *can* - but they have to go to extra steps to do something that
they shouldn't.
There is, of course, no *technical* reason they shouldn't - especially on
RISC OS - but that's why I say it should just be discouraged (and therefore
made a smidgeon more difficult) and not forbidden.
[...]
> I do see your point here, but it does seem more natural to me to drag the
> item to where you want it to go.
that drag ends is the *destination* window: Something has to be dropped,
otherwise it's not drag and *drop*.
(Exceptions are when I take an extra step to have the source window updated
as well - such as pressing an extra key to move a file instead of just copy
it.)
> The problem is when there are multiple items that can be dragged to
> multiple places.
dummy app - because when you do that *the drag and drop actually DROPS
something*.
The suggestion to drag the destination folder to the window was an
alternative suggestion, offered because:
1) Dragging and dropping without something dropping is IMO counter-intuitive
2) You didn't like the suggestion of solving that by dropping the dummy-app
> > > One immediate thought which occurs to me, although I haven't really
> > > looked at your proposal yet so don't know how relevant it'll be,
> > > concerns the setting of default locations. I really would rather have
> > > these be a last-resort thing, because if the filename fields were
> > > already populated with the default locations when the window opened,
> > > and I had a lot of icons to drag, I'd find it difficult to keep track
> > > of which boxes I had already manually updated. I want them blank
> > > until the point of installation, or at least initially differently
> > > coloured to make it plain that the location hasn't been changed from
> > > the package's default.
> > Good point, yes.
> I'm not convinced this is needed, surely you can see where everything is
> going at all times anyway, but a different colour may be the way to go if
> it is needed.
multiple items to drag (and not-drop), of which items have yet to be dragged
(and not-dropped).
Also, if you are going to insist on this bizarre drag and not-drop approach,
then Martin's suggestion would help mitigate things, albeit only slightly,
by providing some form of more *obvious* visual feedback that something's
happened.
(Yes, the contents of the 'Path' icon have changed - but the user's eyes
weren't over there <--- in the PackMan window when they not-dropped the
item, they were all the way over there ---> in the filer window. A change of
text in the corner of someone's eye is likely to be too subtle to notice.)
(Dropping a dummy-app - so you are using drag and drop, rather than drag and
not-drop - would, of course, mean visual feedback is more or less instant,
and in the window in which the user's eyes are focussed at that moment.)
[The current method of moving an installed package]
> > ISTR that coming up in a recent discussion - I can't remember if it was
> > pointed out to me, or I found it while playing, but I do remember
> > thinking that while I was glad there was now a way to move things, I
> > wasn't too impressed with how it's done. I probably said something to
> > that effect.
> I can't really remember this discussion either, but I'm not sure what you
> didn't like about it. Was it just that it took a while to find it? It all
> works with RISC OS menus and drag-and-drop, so I'm unsure what there was
> to dislike.
said it, but failed. I *think* it was something along those lines, though -
that it took too long to find it initially, and therefore felt hidden away,
as though its use was being discouraged.
(To be fair, though, at the time I didn't see the purpose of the Apps
window, which could well be because I'm not a regular user of the software,
except when trying it out.)
Vince M Hudd
May 25, 2013, 6:49:54 AM5/25/13
to
Chris Johnson <chrisjoh...@spamcop.net> wrote:
> In article <53513f3961...@btinternet.com>,
> spampling <spam....@btinternet.com> wrote:
> > BTW the suggestion Vince makes of dragging a folder to the installer
> > strikes me as the reverse of the operation that will take place and is
> > most definitely counter-intuitive
It might sound like it, because if the end of the process would mean !Egg is
> In article <53513f3961...@btinternet.com>,
> spampling <spam....@btinternet.com> wrote:
> > BTW the suggestion Vince makes of dragging a folder to the installer
> > strikes me as the reverse of the operation that will take place and is
> > most definitely counter-intuitive
going to be placed in FryingPan, then you would expect to drop !Egg into
FryingPan.
However, what's happening here is that you are actually not-dropping !Egg
into FryingPan - !Egg will not actually appear in FryingPan until some
arbitrary later point.
Dragging FryingPan onto the installation window for !Egg, in this sense, is
akin to relaying "frying pan" to someone as part of the instructions for
frying an egg, which they will follow later.
> In a couple of my recent apps where paths have to be set up, I decided to
> provide both options. This was after seeing some similar comments in a
> mail list (or newsgroup) and because not all apps do the same. You can
> either drag a dir icon into the destination directory, or drag the
> destination dir into the appropriate writable field in the app. I actually
> think I prefer the former, but each to his own. Now that will really muddy
> the waters.
It might be worth trying them out to see how they feel in use.
(What wwould be interesting is to know how many users actually use one over
the other in *real use* rather than when talking about the merits of the two
different approaches on usenet.)
Vince M Hudd
May 25, 2013, 6:59:55 AM5/25/13
to
spampling <spam....@btinternet.com> wrote:
> BTW the suggestion Vince makes of dragging a folder to the installer
> strikes me as the reverse of the operation that will take place and is
> most definitely counter-intuitive
I have a piece of paper on my desk. I'm going to file it in this file right
> BTW the suggestion Vince makes of dragging a folder to the installer
> strikes me as the reverse of the operation that will take place and is
> most definitely counter-intuitive
here...
WOAH! WAIT! WHAT HAPPENED?
Instead of ending up in the file, the paper is still on my desk, but now it
has the name of the file on it!
Theo Markettos
May 25, 2013, 8:41:06 AM5/25/13
to
Vince M Hudd <vin...@softrock.co.uk> wrote:
> I don't think anyone should ever be *installing* things in the root
> directory.
>
> There are things which can, perfectly reasonably, be placed there, such as
> directories, but I don't think anything should ever be *installed* there.
> The only application directory that ought to be in root is !Boot - which
> isn't supplied by the package manager (and if it was, it'd be a special case
> anyway).
Tis more complicated than that. What about USB devices, where it's quite
> directory.
>
> There are things which can, perfectly reasonably, be placed there, such as
> directories, but I don't think anything should ever be *installed* there.
> The only application directory that ought to be in root is !Boot - which
> isn't supplied by the package manager (and if it was, it'd be a special case
> anyway).
conceivable that people could install things into the root as a 'portable
apps' concept. Or dragging into filer windows opened on FooPath:
(I can't think of any common cases people do that, but there probably are
some).
Coping with transient media gets a bit awkward from the package manager
point of view, but I thought the original point of this discussion was not
railroading people into doing things only one way.
> To me it doesn't. In any drag and drop, what I expect to see updated when
> that drag ends is the *destination* window: Something has to be dropped,
> otherwise it's not drag and *drop*.
> (Exceptions are when I take an extra step to have the source window updated
> as well - such as pressing an extra key to move a file instead of just copy
> it.)
modifier - eg an Adjust-drag or a Shift-drag to say 'use the parent
directory'. Perhaps one route would be to standardise this process?
Theo
Vince M Hudd
May 25, 2013, 8:50:24 AM5/25/13
to
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > I don't think anyone should ever be *installing* things in the root
> > directory.
[...]
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > I don't think anyone should ever be *installing* things in the root
> > directory.
> What about USB devices,
[and other transient media]
Okay - good point. I hadn't considered anything but the boot drive. D'oh!
[...]
> > (Exceptions are when I take an extra step to have the source window
> > updated as well - such as pressing an extra key to move a file instead
> > of just copy it.)
> Previously apps which wanted a directory dropping on them have used some
> modifier - eg an Adjust-drag or a Shift-drag to say 'use the parent
> directory'. Perhaps one route would be to standardise this process?
Tim Hill
May 25, 2013, 8:45:25 AM5/25/13
to
In article <mpro.mncor5003...@softrock.co.uk>, Vince M Hudd
grammatically but you know what it means without 'which'. Computer does
too. ;-)
Shouldn't we work toward the goal of every draggable object also being a
drop target, so all such links /should/ work in either direction? Anyone
finding one method counter-intuitive can use the other instead. I realise
I use both/either method in !Locate and don't give it a second thought.
It is neither confusing nor counter-intuitive. With Locate it depends on
whether I am looking at a viewer into the directory I want to search, or
at a collection of folders and I want to search one/some but not /all/ of
them. (And I love being able to drag to/from the iconbar icon and not
even have to open its main window first, but not relevant here.)
If you imagine having your Apps directory viewer open in front of you as
you are installing stuff, it may contain some apps and some folders. You
may want to install an !app in the root of Apps (so it appears in
Iconbar|Apps|Select) so you drag the app icon to it, or you want it in a
sub-folder of Apps. Being able to drag the sub-directory's folder is
clearly an advantage because you don't have to open it to set it. New
users could otherwise end up with lots of open and confusing filer
windows scattered on their desktop.
If I Adjust/Drag the app icon to a folder what will the different
behaviour be? Could it please close the directory viewer I have just
dragged it to? If I Adjust/Drag to the instally, perhaps the app should
be installed in the parent of the object dragged, or something.
See what I did? Like differences between the use of Adjust and Select
(buttons, not OS versions) dragging in different directions should (and
usually does) have a different outcome where it exists.
> However, what's happening here is that you are actually not-dropping
> !Egg into FryingPan - !Egg will not actually appear in FryingPan until
> some arbitrary later point.
That's because the install process proper has not yet begun. You are just
setting up the install parameters for now which ought to be done without
any changes being made to the disc in case you want to change your mind
before pressing commit, go, install or whatever at the bottom of the
page. I suggest the writable path icon should reveal whether you have set
a path or not (perhaps with a different grey background if it is the
default i.e. 'unset by the user') or something else if you have dragged
or otherwise written to it.
There should be nothing in the directory viewer because there is nothing
installed there yet. AIUI, not until you reach the bottom of the dialogue
and press something will the install proper begin.
> Dragging FryingPan onto the installation window for !Egg, in this
> sense, is akin to relaying "frying pan" to someone as part of the
> instructions for frying an egg, which they will follow later.
That may be so but it's not just Yoda who constructs sentences like that
above.
The dialogue is asking where to save the file and you are showing it
where by dragging a folder to it. There is nothing counter-intuitive in
that.
Store money in wallet
and
Use wallet to store money
are synonymous.
If you use !Locate you ought to get to grips with dragging in both
directions and seeing it as a benefit, rather than something to avoid.
> > In a couple of my recent apps where paths have to be set up, I
> > decided to provide both options. This was after seeing some similar
> > comments in a mail list (or newsgroup) and because not all apps do
> > the same. You can either drag a dir icon into the destination
> > directory, or drag the destination dir into the appropriate writable
> > field in the app. I actually think I prefer the former, but each to
> > his own. Now that will really muddy the waters.
Perhaps, but it depends on whether you want to set a path to the filer
window you are looking at, or to a folder in the viewer you have open.
These two drags, TO or FRO are NOT THE SAME and have a DIFFERENT outcome.
1. To install something called !app, you open root.
You drag the !app icon to it. The install path becomes
$.!app
2. To install something called !app, you open root.
You drag the App folder from $ to the installer. the path becomes
$.App.!app
(2) is easier than having the additional step of opening App's viewer,
particularly if there are many to install. Three clicks less on your RSI
tally for each.
> Insteresting. Which apps?
!Locate lets you do either. It makes perfect sense.
http://www.stevefryatt.org.uk/software/locate/
> It might be worth trying them out to see how they feel in use.
> (What wwould be interesting is to know how many users actually use one
> over the other in *real use* rather than when talking about the merits
> of the two different approaches on usenet.)
Could this be one of those non-negative-issues being worried about by
people who have a tendency to resist any change including useful
additional optional features. ;-D
I agree that unnecessary duplication of function is generally to be
avoided but drags in different directions can both have different,
useful, outcomes and, IMO, both are very worthwhile.
T
<vin...@softrock.co.uk> wrote:
> Chris Johnson <chrisjoh...@spamcop.net> wrote:
> > In article <53513f3961...@btinternet.com>, spampling
> > <spam....@btinternet.com> wrote:
> > > BTW the suggestion Vince makes of dragging a folder to the
> > > installer strikes me as the reverse of the operation that will take
> > > place and is most definitely counter-intuitive
> It might sound like it, because if the end of the process would mean
> !Egg is going to be placed in FryingPan, then you would expect to drop
> !Egg into FryingPan.
'This is the Frying Pan to drop the !Egg into' works too. Perhaps not
> Chris Johnson <chrisjoh...@spamcop.net> wrote:
> > In article <53513f3961...@btinternet.com>, spampling
> > <spam....@btinternet.com> wrote:
> > > BTW the suggestion Vince makes of dragging a folder to the
> > > installer strikes me as the reverse of the operation that will take
> > > place and is most definitely counter-intuitive
> It might sound like it, because if the end of the process would mean
> !Egg is going to be placed in FryingPan, then you would expect to drop
> !Egg into FryingPan.
grammatically but you know what it means without 'which'. Computer does
too. ;-)
Shouldn't we work toward the goal of every draggable object also being a
drop target, so all such links /should/ work in either direction? Anyone
finding one method counter-intuitive can use the other instead. I realise
I use both/either method in !Locate and don't give it a second thought.
It is neither confusing nor counter-intuitive. With Locate it depends on
whether I am looking at a viewer into the directory I want to search, or
at a collection of folders and I want to search one/some but not /all/ of
them. (And I love being able to drag to/from the iconbar icon and not
even have to open its main window first, but not relevant here.)
If you imagine having your Apps directory viewer open in front of you as
you are installing stuff, it may contain some apps and some folders. You
may want to install an !app in the root of Apps (so it appears in
Iconbar|Apps|Select) so you drag the app icon to it, or you want it in a
sub-folder of Apps. Being able to drag the sub-directory's folder is
clearly an advantage because you don't have to open it to set it. New
users could otherwise end up with lots of open and confusing filer
windows scattered on their desktop.
If I Adjust/Drag the app icon to a folder what will the different
behaviour be? Could it please close the directory viewer I have just
dragged it to? If I Adjust/Drag to the instally, perhaps the app should
be installed in the parent of the object dragged, or something.
See what I did? Like differences between the use of Adjust and Select
(buttons, not OS versions) dragging in different directions should (and
usually does) have a different outcome where it exists.
> However, what's happening here is that you are actually not-dropping
> !Egg into FryingPan - !Egg will not actually appear in FryingPan until
> some arbitrary later point.
setting up the install parameters for now which ought to be done without
any changes being made to the disc in case you want to change your mind
before pressing commit, go, install or whatever at the bottom of the
page. I suggest the writable path icon should reveal whether you have set
a path or not (perhaps with a different grey background if it is the
default i.e. 'unset by the user') or something else if you have dragged
or otherwise written to it.
There should be nothing in the directory viewer because there is nothing
installed there yet. AIUI, not until you reach the bottom of the dialogue
and press something will the install proper begin.
> Dragging FryingPan onto the installation window for !Egg, in this
> sense, is akin to relaying "frying pan" to someone as part of the
> instructions for frying an egg, which they will follow later.
above.
The dialogue is asking where to save the file and you are showing it
where by dragging a folder to it. There is nothing counter-intuitive in
that.
Store money in wallet
and
Use wallet to store money
are synonymous.
If you use !Locate you ought to get to grips with dragging in both
directions and seeing it as a benefit, rather than something to avoid.
> > In a couple of my recent apps where paths have to be set up, I
> > decided to provide both options. This was after seeing some similar
> > comments in a mail list (or newsgroup) and because not all apps do
> > the same. You can either drag a dir icon into the destination
> > directory, or drag the destination dir into the appropriate writable
> > field in the app. I actually think I prefer the former, but each to
> > his own. Now that will really muddy the waters.
window you are looking at, or to a folder in the viewer you have open.
These two drags, TO or FRO are NOT THE SAME and have a DIFFERENT outcome.
1. To install something called !app, you open root.
You drag the !app icon to it. The install path becomes
$.!app
2. To install something called !app, you open root.
You drag the App folder from $ to the installer. the path becomes
$.App.!app
(2) is easier than having the additional step of opening App's viewer,
particularly if there are many to install. Three clicks less on your RSI
tally for each.
> Insteresting. Which apps?
!Locate lets you do either. It makes perfect sense.
http://www.stevefryatt.org.uk/software/locate/
> It might be worth trying them out to see how they feel in use.
> (What wwould be interesting is to know how many users actually use one
> over the other in *real use* rather than when talking about the merits
> of the two different approaches on usenet.)
people who have a tendency to resist any change including useful
additional optional features. ;-D
I agree that unnecessary duplication of function is generally to be
avoided but drags in different directions can both have different,
useful, outcomes and, IMO, both are very worthwhile.
T
Tim Hill
May 25, 2013, 8:50:05 AM5/25/13
to
In article <mpro.mncp7v004...@softrock.co.uk>, Vince M Hudd
Paper: for folder.
Fire: for coal.
Coal: for fire.
Still struggling to find these concepts counter-intuitive.
<vin...@softrock.co.uk> wrote:
> spampling <spam....@btinternet.com> wrote:
>
> > BTW the suggestion Vince makes of dragging a folder to the installer
> > strikes me as the reverse of the operation that will take place and
> > is most definitely counter-intuitive
>
> I have a piece of paper on my desk. I'm going to file it in this file
> right here...
> WOAH! WAIT! WHAT HAPPENED?
> Instead of ending up in the file, the paper is still on my desk, but
> now it has the name of the file on it!
Folder: for paper.
> spampling <spam....@btinternet.com> wrote:
>
> > BTW the suggestion Vince makes of dragging a folder to the installer
> > strikes me as the reverse of the operation that will take place and
> > is most definitely counter-intuitive
>
> I have a piece of paper on my desk. I'm going to file it in this file
> right here...
> WOAH! WAIT! WHAT HAPPENED?
> Instead of ending up in the file, the paper is still on my desk, but
> now it has the name of the file on it!
Paper: for folder.
Fire: for coal.
Coal: for fire.
Still struggling to find these concepts counter-intuitive.
Chris Johnson
May 25, 2013, 8:11:05 AM5/25/13
to
In article <mpro.mncor5003...@softrock.co.uk>,
!ConvImgs is one.
--
Chris Johnson
Vince M Hudd <vin...@softrock.co.uk> wrote:
> Insteresting. Which apps?
!ConvImgs is one.
--
Chris Johnson
Vince M Hudd
May 25, 2013, 9:48:41 AM5/25/13
to
Tim Hill <t...@invalid.org.uk> wrote:
> In article <mpro.mncp7v004...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> > I have a piece of paper on my desk. I'm going to file it in this file
> > right here...
> > WOAH! WAIT! WHAT HAPPENED?
> > Instead of ending up in the file, the paper is still on my desk, but now
> > it has the name of the file on it!
> Folder: for paper. Paper: for folder.
> Fire: for coal. Coal: for fire.
Dragging and dropping is an *action*, what you describe in the two lines
> In article <mpro.mncp7v004...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> > I have a piece of paper on my desk. I'm going to file it in this file
> > right here...
> > WOAH! WAIT! WHAT HAPPENED?
> > Instead of ending up in the file, the paper is still on my desk, but now
> > it has the name of the file on it!
> Folder: for paper. Paper: for folder.
> Fire: for coal. Coal: for fire.
above are not.
You can say a folder is for paper and that paper goes in the folder, but
neither is the action of actually putting paper in the folder, whereas
dragging and dropping something from an installer to a filer window is - it
is dropping something into that filer window, so the filer window is updated
with the dropped item. This is why it's called drag and drop.
Dragging and dropping something from a filer window to an installer is also
drag and drop - it's dropping something from the filer window onto the
installer, so the installer window updates with the path of that item.
In either direction, a logical action is being performed - something is
being picked up, dragged to another place, and dropped onto a destination
window, which is then updated to reflect that.
But this drag and not-drop approach is doing exactly the opposite: Something
is being picked up, dragged to another place, and dropped into a destination
window... which isn't then updated to reflect that. Instead, the source
window is being updated - where the user's focus generally isn't.
The only time the source should be updated is when the drag and drop is such
that *both* are updated, such as a file being moved, rather than copied. Or,
to use your two examples above: You put that paper in the folder, it's no
longer where it was before; you put that coal on the fire, it's no longer in
the scuttle - both cases where the source has been updated, but in
*addition* to the destination, not instead of it.
> Still struggling to find these concepts counter-intuitive.
Vince M Hudd
May 25, 2013, 10:19:30 AM5/25/13
to
Chris Johnson <chrisjoh...@spamcop.net> wrote:
> In article <mpro.mncor5003...@softrock.co.uk>,
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > Insteresting. Which apps?
> !ConvImgs is one.
I've just tried it.
> In article <mpro.mncor5003...@softrock.co.uk>,
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > Insteresting. Which apps?
> !ConvImgs is one.
And I have to say that dragging the folder icon from the window to a
directory viewer and not have something appear when I dropped the icon felt
wrong.
If I use that app, my inclination would be to drag a target folder onto the
path, so that it feels more natural, with the drop resulting in the target
window being updated.
I did actually try a little experiment:
I typed 'Test' into the writable icon and then dragged the folder icon, to
see if a folder called 'Test' would appear. It didn't: The path became the
directory into which I not-dropped the folder. TBH, I think that actually
makes the drag and not-drop approach even worse.
One thing I did like, though - and which Alan should perhaps take note of -
is the use of the pop-up menu icon to present the draggable icon. Doing this
would perhaps reduce the size of the window, especially when presenting the
user with multiple items to drag and drop (or drag and not-drop, whichever
approach is eventually used).
Having said that, with the boot-options trinity included as well, there may
not be that much of a space saving, unless an alternative way of presenting
these is considered. (How about a menu selection for the trinity: do
nothing, or boot/add to apps/run? That would then fit on a single line
alongside the path).
Tim Hill
May 25, 2013, 10:43:40 AM5/25/13
to
In article <mpro.mncx15004...@softrock.co.uk>, Vince M Hudd
<vin...@softrock.co.uk> wrote:
[Snip]
> > Still struggling to find these concepts counter-intuitive.
> Still struggling to find the idea of drag and not-drop anything but.
I suppose it is just that other instances of 'drag to set a path' exist
so it doesn't seem wrong though I accept what you say about a visual
indication. I suppose it wouldn't do any harm in if a skeleton object to
be installed were created in the target directory, so long as it is
deleted if the install is aborted but it wouldn't make any sense with
Locate to create an object in the target. They both work in the same way:
both installer and Locate has been 'told' the install path and it is
displayed in the main window in a writable icon.
Or do you mean that the install should occur from the moment the
drag'n'drop is completed? I don't think that is the author's intent. The
installs all take place when they have /all/ had paths set and are /all/
committed to.
<vin...@softrock.co.uk> wrote:
[Snip]
> > Still struggling to find these concepts counter-intuitive.
> Still struggling to find the idea of drag and not-drop anything but.
so it doesn't seem wrong though I accept what you say about a visual
indication. I suppose it wouldn't do any harm in if a skeleton object to
be installed were created in the target directory, so long as it is
deleted if the install is aborted but it wouldn't make any sense with
Locate to create an object in the target. They both work in the same way:
both installer and Locate has been 'told' the install path and it is
displayed in the main window in a writable icon.
Or do you mean that the install should occur from the moment the
drag'n'drop is completed? I don't think that is the author's intent. The
installs all take place when they have /all/ had paths set and are /all/
committed to.
Vince M Hudd
May 25, 2013, 11:05:53 AM5/25/13
to
Tim Hill <t...@invalid.org.uk> wrote:
> In article <mpro.mncor5003...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
[...]
> In article <mpro.mncor5003...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> 'This is the Frying Pan to drop the !Egg into' works too.
still not the same as carrying out the action of picking up the egg and
dropping it into the frying pan.
You could perhaps make a case for miming the action - but then you are
updating neither the source nor the destination.
[...]
> Shouldn't we work toward the goal of every draggable object also being a
> drop target, so all such links /should/ work in either direction?
In the specific case of these installation paths for packages in PackMan
(FAO Alan): Yes, why not?
Being able to drag to the window, as well as from it, would work for me
because I'll be able to do what is logical and sane while simultaneously
sticking my fingers in my ears and saying "LALALALALALALA" at the idea that
other people like the drag and not-drop alternative which is also
implemented and working.
[...]
> Could this be one of those non-negative-issues being worried about by
> people who have a tendency to resist any change including useful
> additional optional features. ;-D
to resist change - except where change is to something illogical, less
efficient, less well thought out, counter-intuitive, or any number of other
negative attributes that I can't be bothered to think up, including just
plain old stupid. Individually, or in any combination.
Martin Bazley
May 25, 2013, 11:25:16 AM5/25/13
to
The following bytes were arranged on 25 May 2013 by Vince M Hudd :
> Tim Hill <t...@invalid.org.uk> wrote:
> > Still struggling to find these concepts counter-intuitive.
>
> Still struggling to find the idea of drag and not-drop anything but.
Can we just agree that both methods of working have their own merits
based on the specific circumstances in which you use the application,
which might not be the same each time? Drag-to-window is faster if you
don't already have the folder in which you wish to install the program
open. Drag-to-folder is faster if you do, or if the folder is the
root[*].
A lot of times, if I'm installing something in, say, the Utilities
folder, I'll already have that folder open so that I can see the
applications already in it, and wouldn't want to have to open its parent
before being allowed to install anything inside it.
Providing both features will hurt nobody. Nobody's forcing you to do it
any one specific way.
[*] And I really think you could do with a little reminder of what we're
talking about here: the exact system which has become the single most
notorious example in RISC OS history of attempting to foist its author's
idea of what constituted good practice upon its users, with minimal or
derisory regard for how the users actually liked to keep their discs.
Your complete dismissal of users who might want to install something in
the root of a disc, with accompanying suggestion that such things should
be made purposefully inconvenient, treads dangerously close to the ethos
of RiscPkg's bad old days, of which I seem to remember you were one of
the most vocal critics.
--
__<^>__
/ _ _ \ It is written that Geeks shall inherit the Earth.
> Tim Hill <t...@invalid.org.uk> wrote:
> > Still struggling to find these concepts counter-intuitive.
>
> Still struggling to find the idea of drag and not-drop anything but.
based on the specific circumstances in which you use the application,
which might not be the same each time? Drag-to-window is faster if you
don't already have the folder in which you wish to install the program
open. Drag-to-folder is faster if you do, or if the folder is the
root[*].
A lot of times, if I'm installing something in, say, the Utilities
folder, I'll already have that folder open so that I can see the
applications already in it, and wouldn't want to have to open its parent
before being allowed to install anything inside it.
Providing both features will hurt nobody. Nobody's forcing you to do it
any one specific way.
[*] And I really think you could do with a little reminder of what we're
talking about here: the exact system which has become the single most
notorious example in RISC OS history of attempting to foist its author's
idea of what constituted good practice upon its users, with minimal or
derisory regard for how the users actually liked to keep their discs.
Your complete dismissal of users who might want to install something in
the root of a disc, with accompanying suggestion that such things should
be made purposefully inconvenient, treads dangerously close to the ethos
of RiscPkg's bad old days, of which I seem to remember you were one of
the most vocal critics.
--
__<^>__
/ _ _ \ It is written that Geeks shall inherit the Earth.
( ( |_| ) )
Vince M Hudd
May 25, 2013, 11:27:38 AM5/25/13
to
Tim Hill <t...@invalid.org.uk> wrote:
> In article <mpro.mncx15004...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> [Snip]
> > > Still struggling to find these concepts counter-intuitive.
> > Still struggling to find the idea of drag and not-drop anything but.
> I suppose it is just that other instances of 'drag to set a path' exist
But not in anything I use AFAIK - and if what I know is wrong, then it's in
> In article <mpro.mncx15004...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> [Snip]
> > > Still struggling to find these concepts counter-intuitive.
> > Still struggling to find the idea of drag and not-drop anything but.
> I suppose it is just that other instances of 'drag to set a path' exist
features or options that I don't use. I'd have complained about how crap it
is before now if it was!
> so it doesn't seem wrong though I accept what you say about a visual
> indication. I suppose it wouldn't do any harm in if a skeleton object to
> be installed were created in the target directory,
<mpro.mn47xq008...@softrock.co.uk>, where I wrote:
----<----
The problem is that dragging and dropping something, with that something not
then dropping (IYSWIM) just seems wrong. I wonder if the drop could drop
something - perhaps a pseudo-app that, when run, simply invokes PackMan,
which in turn informs the user that installation is not yet complete, with a
button to proceed with the installation.
(This could also be achieved by saving a file where the icon was dropped,
given the name of the app - but then you'd need to register a filetype, and
that would be a waste of a filetype IMO.)
----8<----
then dropping (IYSWIM) just seems wrong. I wonder if the drop could drop
something - perhaps a pseudo-app that, when run, simply invokes PackMan,
which in turn informs the user that installation is not yet complete, with a
button to proceed with the installation.
(This could also be achieved by saving a file where the icon was dropped,
given the name of the app - but then you'd need to register a filetype, and
that would be a waste of a filetype IMO.)
> so long as it is deleted if the install is aborted
[...]
> Or do you mean that the install should occur from the moment the
> drag'n'drop is completed? I don't think that is the author's intent. The
> installs all take place when they have /all/ had paths set and are /all/
> committed to.
installation should occur in response to the drop (before Alan explained the
purpose of the package list at the top of the window) - but in that same
post I conceded that wouldn't work for packages with multiple items that
could be dragged.
It was a result of Alan's explanation that I made the pseudo-app suggestion
quoted above.
Vince M Hudd
May 25, 2013, 11:46:22 AM5/25/13
to
Martin Bazley <martin...@blueyonder.co.uk> wrote:
> The following bytes were arranged on 25 May 2013 by Vince M Hudd :
> > Tim Hill <t...@invalid.org.uk> wrote:
[...]
> The following bytes were arranged on 25 May 2013 by Vince M Hudd :
> > Tim Hill <t...@invalid.org.uk> wrote:
> [*] And I really think you could do with a little reminder of what we're
> talking about here: the exact system which has become the single most
> notorious example in RISC OS history of attempting to foist its author's
> idea of what constituted good practice upon its users, with minimal or
> derisory regard for how the users actually liked to keep their discs. Your
> complete dismissal of users who might want to install something in the
> root of a disc, with accompanying suggestion that such things should be
> made purposefully inconvenient, treads dangerously close to the ethos of
> RiscPkg's bad old days, of which I seem to remember you were one of the
> most vocal critics.
Except I haven't actually said "You *must* do it my way" and "You *must not*
use the strange 'drag and not-drop' approach." - I've tried to suggest
alternatives that could work and be logical while being very vocal about
explaining why I think it's wrong, using a variety of different examples.
Being very vocal in one's disagreement is *not, IMO, anything like what I
shall henceforth describe as "doing a RiscPkg" - even if I criticise drag
and not-drop to the point of being derisive about it.
And FWIW, although these posts have probably crossed, so when you wrote the
above you may not yet have seen it, I will point out that I have already
said in this thread, earlier this afternoon:
"Being able to drag to the window, as well as from it, would work for me
because I'll be able to do what is logical and sane while simultaneously
sticking my fingers in my ears and saying "LALALALALALALA" at the idea that
other people like the drag and not-drop alternative which is also
implemented and working."
Tim Hill
May 25, 2013, 12:04:44 PM5/25/13
to
In article <mpro.mnd2ha002...@softrock.co.uk>, Vince M Hudd
<vin...@softrock.co.uk> wrote:
[Snip]
> "Being able to drag to the window, as well as from it, would work for
> me because I'll be able to do what is logical and sane while
> simultaneously sticking my fingers in my ears and saying
> "LALALALALALALA" at the idea that other people like the drag and
> not-drop alternative which is also implemented and working."
Ha.
Looking at an app in which one sets paths (such as the excellent
Webchange!) it is not a huge stretch to realise that another method of
setting the path could exist (apart from dragging the target folder to
it). A little not-yet-extant icon to the left of the word 'Path' in its
window could be dragged into a target directory which is already open,
instead of having to open the parent directory so as to drag the target
to the text icon.
I guess not to expect that to be implemented anytime soon. ;-D
<vin...@softrock.co.uk> wrote:
[Snip]
> "Being able to drag to the window, as well as from it, would work for
> me because I'll be able to do what is logical and sane while
> simultaneously sticking my fingers in my ears and saying
> "LALALALALALALA" at the idea that other people like the drag and
> not-drop alternative which is also implemented and working."
Looking at an app in which one sets paths (such as the excellent
Webchange!) it is not a huge stretch to realise that another method of
setting the path could exist (apart from dragging the target folder to
it). A little not-yet-extant icon to the left of the word 'Path' in its
window could be dragged into a target directory which is already open,
instead of having to open the parent directory so as to drag the target
to the text icon.
I guess not to expect that to be implemented anytime soon. ;-D
Vince M Hudd
May 25, 2013, 12:33:58 PM5/25/13
to
Tim Hill <t...@invalid.org.uk> wrote:
> In article <mpro.mnd2ha002...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
[...]
> In article <mpro.mnd2ha002...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> Looking at an app in which one sets paths (such as the excellent
> Webchange!) it is not a huge stretch to realise that another method of
> setting the path could exist (apart from dragging the target folder to
> it). A little not-yet-extant icon to the left of the word 'Path' in its
> window could be dragged into a target directory which is already open,
> instead of having to open the parent directory so as to drag the target to
> the text icon.
> I guess not to expect that to be implemented anytime soon. ;-D
to say "the parent of this" rather than just "this", I did add that to my
to-do list.
I'm also considering adding something to the general choices window:
"Use drag and not-drop instead of drag and drop [ ]"
When ticked, if you drag an icon from a save dialogue - such as a validation
file - then the file won't be saved there and then. Instead, the path shown
in the dialogue for that file will just be updated to show where you intend
for the file to be saved. The save will happen when "Okay" is clicked. :p
Theo Markettos
May 25, 2013, 12:44:54 PM5/25/13
to
Vince M Hudd <vin...@softrock.co.uk> wrote:
> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> > Previously apps which wanted a directory dropping on them have used some
> > modifier - eg an Adjust-drag or a Shift-drag to say 'use the parent
> > directory'. Perhaps one route would be to standardise this process?
>
> That's a sensible idea.
I've just realised a flaw, though. Say you format a new disc and want to
> > Previously apps which wanted a directory dropping on them have used some
> > modifier - eg an Adjust-drag or a Shift-drag to say 'use the parent
> > directory'. Perhaps one route would be to standardise this process?
>
> That's a sensible idea.
install something on it. How do you Adjust-drag something from an empty
window? The only way would seem to be to create a file or directory first
that you can drag, which seems counter-intuitive to me. By this point I
think it's becoming too counter-intuitive to be workable.
The idea of a 'grappling hook' or something to attach a path to a window
while clearly not being a save is an interesting one - come up with an icon
to drag which is clearly not a file-save but expresses a 'linking' action. One
idea of doing that might be a 'hook with chain' graphic (maybe even with the
'chain' played out as you drag) so it's clear it's not an ordinary save.
Theo
Chris Johnson
May 25, 2013, 12:20:56 PM5/25/13
to
In article <mpro.mncygi005...@softrock.co.uk>,
number of other apps do it. One is not, after all, actually saving
anything at this point, so why should anything appear in the target
until the processing actually starts? The pseudo save as dbox, which
contains only the dir icon to be dragged could be extended to include
a writable icon for the final directory name. However, the normal
save as protocol will not normally create folders if they do not
already exist. I wonder if this is getting more complicated than it
need to be.
--
Chris Johnson
Vince M Hudd <vin...@softrock.co.uk> wrote:
> I typed 'Test' into the writable icon and then dragged the folder
> icon, to see if a folder called 'Test' would appear. It didn't: The
> path became the directory into which I not-dropped the folder. TBH,
> I think that actually makes the drag and not-drop approach even
> worse.
Interesting thoughts, although the way I do it is, I think, the way a
> I typed 'Test' into the writable icon and then dragged the folder
> icon, to see if a folder called 'Test' would appear. It didn't: The
> path became the directory into which I not-dropped the folder. TBH,
> I think that actually makes the drag and not-drop approach even
> worse.
number of other apps do it. One is not, after all, actually saving
anything at this point, so why should anything appear in the target
until the processing actually starts? The pseudo save as dbox, which
contains only the dir icon to be dragged could be extended to include
a writable icon for the final directory name. However, the normal
save as protocol will not normally create folders if they do not
already exist. I wonder if this is getting more complicated than it
need to be.
--
Chris Johnson
Vince M Hudd
May 25, 2013, 2:52:50 PM5/25/13
to
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
[Using a modified drag to mean "use this object's parent"]
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> > That's a sensible idea.
> I've just realised a flaw, though. Say you format a new disc and want to
> install something on it. How do you Adjust-drag something from an empty
> window? The only way would seem to be to create a file or directory first
> that you can drag, which seems counter-intuitive to me. By this point I
> think it's becoming too counter-intuitive to be workable.
I still don't like drag and not-drop, though - flaws with edge cases for
what I consider a much preferable alternative aren't going to change that.
(And note that my original suggestion of dropping a pseudo-app wouldn't be
subject to this particular flaw - though that's only a suggestion applicable
to PackMan; other apps need other solutions, appropriate to what they are
not-dropping.)
> The idea of a 'grappling hook' or something to attach a path to a window
> while clearly not being a save is an interesting one - come up with an
> icon to drag which is clearly not a file-save but expresses a 'linking'
> action.
dragged and later created: If that's a folder, then the icon needs to be a
folder-plus-chain (or whatever rather than chain); if it's an application,
then a standard app-dir-plus-chain.
> One idea of doing that might be a 'hook with chain' graphic (maybe even
> with the 'chain' played out as you drag) so it's clear it's not an
> ordinary save.
not RISC OS. Or something.
Vince M Hudd
May 25, 2013, 3:09:47 PM5/25/13
to
Chris Johnson <chrisjoh...@spamcop.net> wrote:
> In article <mpro.mncygi005...@softrock.co.uk>,
> Vince M Hudd <vin...@softrock.co.uk> wrote:
[ConvImgs]
> In article <mpro.mncygi005...@softrock.co.uk>,
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > I typed 'Test' into the writable icon and then dragged the folder icon,
> > to see if a folder called 'Test' would appear. It didn't: The path
> > became the directory into which I not-dropped the folder. TBH, I think
> > that actually makes the drag and not-drop approach even worse.
> Interesting thoughts, although the way I do it is, I think, the way a
> number of other apps do it.
I would be interested in knowing how far back this method goes - and in
particular, who first implemented it. Mainly because, prior to the two
examples given in this thread - ConvImgs and Locate - I had thought Alan's
use of it was the first. When I mention any given developer on RISCOSitory,
I like to add a little, such as:
"Chris Johnson, well known for a number of applications, in particular the
likes of Snapper and SyncDiscs, both of which began life with David Pilling
and later taken over by Chris..."
On the basis that I thought Alan was [going to be] the first to do this, I
had already earmarked "inventor of the drag and not-drop protocol on RISC
OS" for him, but it seems the accolade really belongs to somebody else.
In fact, if I wasn't so far behind, and was able to post something pointing
people towards his test app, I might have headlined it along the lines of
"Coming soon to RISC OS: Drag and not-drop" - incorrectly if it's already in
use - but if I continue with my current approach of only devoting time to
RISCOSitory that keeps my total working week sensible, while plugging away
at the backlog in the order it came in, it'll be somewhat after the fact as
regards the test app.
I suppose there's always something like "PackMan gains drag and not-drop
interface" if/when it does get implemented.
> One is not, after all, actually saving anything at this point, so why
> should anything appear in the target until the processing actually starts?
read the instructions - so I'm only assuming that what it does is use the
directory set via that window as the destination for any converted images.
With that in mind, the logic of my test above was that I would be creating a
directory into which those converted images would be saved. I therefore
expected that 'Test' directory to be created, which would have been positive
feedback in the window that was the target of my drag and drop.
This struck me as logical and intuitive - but didn't work, as I said. To be
fair, though, I should probably have taken the fact that the writable icon
wasn't in the [pseudo] save dialogue as a bit of a clue.
A question, though: Given that the path can be updated by dragging the
folder icon from the pseudo save dialogue, *or* by dragging a folder icon
onto the path itself, why does it need to be writable? At what point do you
envisage a user putting the cursor in that icon and modifying it?
Perhaps if that wasn't possible, I wouldn't have tried to create a folder
that way.
> The pseudo save as dbox, which contains only the dir icon to be dragged
> could be extended to include a writable icon for the final directory name.
> However, the normal save as protocol will not normally create folders if
> they do not already exist. I wonder if this is getting more complicated
> than it need to be.
The normal save as will also not create files if they don't already exist -
it's the job of the application implementing the save to create (save) the
file, and I'd expect the same if what is being dragged and dropped is a
folder icon. In fact, that *is* what happens in the filer if you create a
new directory:
You get a standard RISC OS save dialogue, with a folder icon and a writable
icon for the name. Type the name in, drag the folder to a directory viewer
and drop it: hey presto.
druck
May 25, 2013, 4:18:11 PM5/25/13
to
On 23/05/2013 19:27, Martin Bazley wrote:
Unfortunately, this type of user interface design has one major drawback
> which its proponents have never adequately answered: what happens if you
> want to install to the root of a disc? What do you drag then?
The drive icon on the iconbar. Some, but not all, filers support this.
Unfortunately, this type of user interface design has one major drawback
> which its proponents have never adequately answered: what happens if you
> want to install to the root of a disc? What do you drag then?
---druck
druck
May 25, 2013, 4:26:44 PM5/25/13
to
On 25/05/2013 19:52, Vince M Hudd wrote:
> Cue Druck to complain about silly animations, which is what Windows does,
> not RISC OS. Or something.
I don't like a pointless animation of something moving, but I don't mind
> Cue Druck to complain about silly animations, which is what Windows does,
> not RISC OS. Or something.
a Windows 8 style graph of read/write speeds. At least not on a system
with background I/O, plenty of idle CPU cores and accelerated graphics.
---druck
Chris Johnson
May 25, 2013, 7:10:07 PM5/25/13
to
In article <mpro.mndbwa002...@softrock.co.uk>,
Transient or TempDir would want to save files in the current days
folder. Dragging would set the path to a specific date, whereas
entering manually eg <Transient$TodayDir> would save them in the
current days directory, whatever that might be.
Any use of a path variable eg <MyApp$Dir>.^
--
Chris Johnson
Vince M Hudd <vin...@softrock.co.uk> wrote:
> A question, though: Given that the path can be updated by dragging
> the folder icon from the pseudo save dialogue, *or* by dragging a
> folder icon onto the path itself, why does it need to be writable?
> At what point do you envisage a user putting the cursor in that
> icon and modifying it?
Perhaps a user of one of the temporary directory apps such as
> A question, though: Given that the path can be updated by dragging
> the folder icon from the pseudo save dialogue, *or* by dragging a
> folder icon onto the path itself, why does it need to be writable?
> At what point do you envisage a user putting the cursor in that
> icon and modifying it?
Transient or TempDir would want to save files in the current days
folder. Dragging would set the path to a specific date, whereas
entering manually eg <Transient$TodayDir> would save them in the
current days directory, whatever that might be.
Any use of a path variable eg <MyApp$Dir>.^
--
Chris Johnson
spampling
May 26, 2013, 4:55:41 AM5/26/13
to
In article <mpro.mncp7v004...@softrock.co.uk>, Vince M Hudd
write a small note on it and the robo-secretary will put it in the selected
location (unless the robo-secretary knows this is a critical document and
it therefore needs to be with the other critical documents)
--
Steve Pampling
<vin...@softrock.co.uk> wrote:
> spampling <spam....@btinternet.com> wrote:
> > BTW the suggestion Vince makes of dragging a folder to the installer
> > strikes me as the reverse of the operation that will take place and is
> > most definitely counter-intuitive
> I have a piece of paper on my desk. I'm going to file it in this file
> right here...
> WOAH! WAIT! WHAT HAPPENED?
> Instead of ending up in the file, the paper is still on my desk, but now
> it has the name of the file on it!
I have a piece of paper that needs filing in the file over there - I will
> spampling <spam....@btinternet.com> wrote:
> > BTW the suggestion Vince makes of dragging a folder to the installer
> > strikes me as the reverse of the operation that will take place and is
> > most definitely counter-intuitive
> I have a piece of paper on my desk. I'm going to file it in this file
> right here...
> WOAH! WAIT! WHAT HAPPENED?
> Instead of ending up in the file, the paper is still on my desk, but now
> it has the name of the file on it!
write a small note on it and the robo-secretary will put it in the selected
location (unless the robo-secretary knows this is a critical document and
it therefore needs to be with the other critical documents)
--
Steve Pampling
spampling
May 26, 2013, 4:51:12 AM5/26/13
to
In article <mpro.mndb42001...@softrock.co.uk>,
which calls the transfer process occasionally.
When the underlying process is used without the animation it all happens
way faster.
If people using RISC OS want an optional[1] animation that is updated at
intervals then fine.
The windows way tries to make a process amusing and fails because of the
introduced delay making the whole thing tedious.
[1] Optional - that means you can turn it ON if you want.
--
Steve Pampling
Vince M Hudd <vin...@softrock.co.uk> wrote:
> Cue Druck to complain about silly animations, which is what Windows does,
> not RISC OS. Or something.
Nah, the problem there (Windows) is that the animation is the main process
> Cue Druck to complain about silly animations, which is what Windows does,
> not RISC OS. Or something.
which calls the transfer process occasionally.
When the underlying process is used without the animation it all happens
way faster.
If people using RISC OS want an optional[1] animation that is updated at
intervals then fine.
The windows way tries to make a process amusing and fails because of the
introduced delay making the whole thing tedious.
[1] Optional - that means you can turn it ON if you want.
--
Steve Pampling
Bryn Evans
May 26, 2013, 6:10:18 AM5/26/13
to
In a mad moment - druck mumbled :
I may be wrong about this :( but-
When I upgreaded to !MessengerPro v.7.06 I seem to remember a Window
which asked where I wanted to place/instal !NewsDir.
The Default suggested was inside !Boot and this was shown in a small
writable window. However there was an Icon inside the window which
offered the choice of Dragging a Destination directory to it, after
which the destination replaced the Default (!Boot).
If you were happy with that, then all that remained was to click on
the button to Continue the installation/upgrade. Simples!
I found it quite easy to follow and seem a sensible way to for the
user to control their choices.
As far a Bulk Installs go, I would much rather do them one at a time.
That way there is less chance of dumping something in the wrong place
by rushing the job.
--
|)����[
|)ryn [vans mail to - Bryn...@bryork.freeuk.com
When I upgreaded to !MessengerPro v.7.06 I seem to remember a Window
which asked where I wanted to place/instal !NewsDir.
The Default suggested was inside !Boot and this was shown in a small
writable window. However there was an Icon inside the window which
offered the choice of Dragging a Destination directory to it, after
which the destination replaced the Default (!Boot).
If you were happy with that, then all that remained was to click on
the button to Continue the installation/upgrade. Simples!
I found it quite easy to follow and seem a sensible way to for the
user to control their choices.
As far a Bulk Installs go, I would much rather do them one at a time.
That way there is less chance of dumping something in the wrong place
by rushing the job.
--
|)����[
|)ryn [vans mail to - Bryn...@bryork.freeuk.com
Tim Hill
May 26, 2013, 6:05:03 AM5/26/13
to
In article <mpro.mndbwa002...@softrock.co.uk>, Vince M Hudd
icon/drop target and clearly shows the path selected or chosen by default
(in different colours?!).
A writable icon may be useful:
0. Cut'n'paste
Imagine leaving an email note for another user: "I have installed
!app in its default folder. Can't tell you where it is because the
installer app wouldn't let me Copy the path. Happy hunting."
1. Because I dragged an object from the root directory to set the path
and actually wanted to set it to the root of a device.
2. Because I have two hard drives and one is a duplicate of the other. I
can duplicate a backup path quickly, just by changing the drive number.
3. It is quite common to provide users with several ways of doing
something slightly differently and to provide choice. I am sure there us
a reason on windows for <Ctrl>S, 'Save as' icon, strip menu 'Save as'
option, and context menu 'Save as' option. (Okay, I accept that reason
/may/ be stupidity.)
4. Some people like to type things and don't trust a GUI. Look at the
command line geeks embracing the pi.
Qs. If I type directory names which do not exist into the path, will they
be created? Will each path be parsed for validity? Not having a writable
icon potentially saves trouble as only valid paths can be dragged.
(Vince, this has made me remember that there have been times when I used
to grumble to myself and wished that WebChange had a writable icon for
the path, so as to get at the directory I already have open in front of
me. From experience with other apps, I expect to be able to drag anything
from the folder and then delete the leafname. I have instead learnt not
to do that.)
I /do/ see the logic in NOT providing a /writable/ icon, providing /any/
valid path can be created without it! Dragging only folders to register a
path does not provide this, unless a modifier were to be introduced such
that Shift/Drag to register the parent path of an object, or the leafname
of a non-folder object was discarded.
<vin...@softrock.co.uk> wrote:
> A question, though: Given that the path can be updated by dragging the
> folder icon from the pseudo save dialogue, *or* by dragging a folder
> icon onto the path itself, why does it need to be writable? At what
> point do you envisage a user putting the cursor in that icon and
> modifying it?
Perhaps it doesn't need to be writable, so long as it is near the drag
> A question, though: Given that the path can be updated by dragging the
> folder icon from the pseudo save dialogue, *or* by dragging a folder
> icon onto the path itself, why does it need to be writable? At what
> point do you envisage a user putting the cursor in that icon and
> modifying it?
icon/drop target and clearly shows the path selected or chosen by default
(in different colours?!).
A writable icon may be useful:
0. Cut'n'paste
Imagine leaving an email note for another user: "I have installed
!app in its default folder. Can't tell you where it is because the
installer app wouldn't let me Copy the path. Happy hunting."
1. Because I dragged an object from the root directory to set the path
and actually wanted to set it to the root of a device.
2. Because I have two hard drives and one is a duplicate of the other. I
can duplicate a backup path quickly, just by changing the drive number.
3. It is quite common to provide users with several ways of doing
something slightly differently and to provide choice. I am sure there us
a reason on windows for <Ctrl>S, 'Save as' icon, strip menu 'Save as'
option, and context menu 'Save as' option. (Okay, I accept that reason
/may/ be stupidity.)
4. Some people like to type things and don't trust a GUI. Look at the
command line geeks embracing the pi.
Qs. If I type directory names which do not exist into the path, will they
be created? Will each path be parsed for validity? Not having a writable
icon potentially saves trouble as only valid paths can be dragged.
(Vince, this has made me remember that there have been times when I used
to grumble to myself and wished that WebChange had a writable icon for
the path, so as to get at the directory I already have open in front of
me. From experience with other apps, I expect to be able to drag anything
from the folder and then delete the leafname. I have instead learnt not
to do that.)
I /do/ see the logic in NOT providing a /writable/ icon, providing /any/
valid path can be created without it! Dragging only folders to register a
path does not provide this, unless a modifier were to be introduced such
that Shift/Drag to register the parent path of an object, or the leafname
of a non-folder object was discarded.
Tim Hill
May 26, 2013, 6:13:54 AM5/26/13
to
In article <mpro.mnd4om004...@softrock.co.uk>, Vince M Hudd
<vin...@softrock.co.uk> wrote:
[Snip]
> When ticked, if you drag an icon from a save dialogue - such as a
> validation file - then the file won't be saved there and then. Instead,
> the path shown in the dialogue for that file will just be updated to
> show where you intend for the file to be saved. The save will happen
> when "Okay" is clicked. :p
:-D
I can think of at least two people who would love that.
One has a habit of writing a document and then the checking process
consists of adding all the dictionary-checked mis-spelled word to the
dictionary. Then he goes into the dictionary and decides /out of context/
whether his spellings are right or not (most are not but he thinks they
are) deletes those which are wrong in his mind and then re-checks his
document. Sometimes repeating this process. He used to work on Government
IT contracts so make some assumptions!
The other thinks that computer OSes don't have anything like enough 'Are
you sure' boxes which simply irritate the hell out of all of the rest of
us who search for ways to switch them all off, not to create more.
<vin...@softrock.co.uk> wrote:
[Snip]
> When ticked, if you drag an icon from a save dialogue - such as a
> validation file - then the file won't be saved there and then. Instead,
> the path shown in the dialogue for that file will just be updated to
> show where you intend for the file to be saved. The save will happen
> when "Okay" is clicked. :p
I can think of at least two people who would love that.
One has a habit of writing a document and then the checking process
consists of adding all the dictionary-checked mis-spelled word to the
dictionary. Then he goes into the dictionary and decides /out of context/
whether his spellings are right or not (most are not but he thinks they
are) deletes those which are wrong in his mind and then re-checks his
document. Sometimes repeating this process. He used to work on Government
IT contracts so make some assumptions!
The other thinks that computer OSes don't have anything like enough 'Are
you sure' boxes which simply irritate the hell out of all of the rest of
us who search for ways to switch them all off, not to create more.
Martin Bazley
May 26, 2013, 9:22:38 AM5/26/13
to
The following bytes were arranged on 25 May 2013 by Vince M Hudd :
> (And note that my original suggestion of dropping a pseudo-app wouldn't be
> subject to this particular flaw - though that's only a suggestion applicable
> to PackMan; other apps need other solutions, appropriate to what they are
> not-dropping.)
Your pseudo-app suggestion conflicts with one of the major changes which
> subject to this particular flaw - though that's only a suggestion applicable
> to PackMan; other apps need other solutions, appropriate to what they are
> not-dropping.)
needs to be made to the package format, and indeed is part of the reason
the window has been designed the way it is in the first place: the
ability to install things which are *not* application directories.
What do you do when you want to install a BASIC program, for example?
(At the moment, the answer is "you can't cos the package format is
stupid", but I'm hoping that's going to change.)
--
__<^>__ "Start off every day with a smile and get it over with."
/ _ _ \ - W.C. Fields
Martin Bazley
May 26, 2013, 9:28:17 AM5/26/13
to
The following bytes were arranged on 25 May 2013 by Vince M Hudd :
> Chris Johnson <chrisjoh...@spamcop.net> wrote:
> > Interesting thoughts, although the way I do it is, I think, the way a
> > number of other apps do it.
>
> None, AFAIK, that I use - as I've said in another post.
>
> I would be interested in knowing how far back this method goes - and in
> particular, who first implemented it. Mainly because, prior to the two
> examples given in this thread - ConvImgs and Locate - I had thought Alan's
> use of it was the first.
Since you seem fond of linking to the Bazley website lately, here's
> > Interesting thoughts, although the way I do it is, I think, the way a
> > number of other apps do it.
>
> None, AFAIK, that I use - as I've said in another post.
>
> I would be interested in knowing how far back this method goes - and in
> particular, who first implemented it. Mainly because, prior to the two
> examples given in this thread - ConvImgs and Locate - I had thought Alan's
> use of it was the first.
another one for you to consider - ScreenGrabber:
http://www.starfighter.acornarcade.com/mysite/utilities.htm#screengrabber
--
__<^>__
/ _ _ \ You always find something in the last place you look.
Martin Bazley
May 26, 2013, 9:30:33 AM5/26/13
to
The following bytes were arranged on 25 May 2013 by druck :
You can drag *to* the drive icon. You most certainly cannot drag the
drive icon *itself* to the window, which was the problem with the method
under discussion. I think you've got yourself confused.
--
__<^>__ "Start off every day with a smile and get it over with."
/ _ _ \ - W.C. Fields
drive icon *itself* to the window, which was the problem with the method
under discussion. I think you've got yourself confused.
--
__<^>__ "Start off every day with a smile and get it over with."
/ _ _ \ - W.C. Fields
Matthew Phillips
May 26, 2013, 5:18:50 PM5/26/13
to
In message <mpro.mndbwa002...@softrock.co.uk>
icon next to a writable icon where the backup path is set, which the user can
drag to a directory to set the backup location. If you drag it to the root
of the RAM disc, for example, then RAM::RamDisc0.$ appears in the writable
icon.
The backups that Impact produce entail creating a directory in the backup
location anyway, so the metaphor is not too bad, and the fact it is a small
directory icon, just to the right of the writable icon, helps to distinguish
it from a standard save box.
If you drag a directory from a Filer window to the writable icon, the full
pathname is placed in the writable icon. So users can do whichever feels
more natural. Much better to give the user both options, I think.
This doesn't answer your question, as to who first implemented
drag-and-not-drop, as I doubt anyone else has copied the idea from a fairly
obscure window in Impact! I am pretty sure I had seen the idea elsewhere
before I implemented it myself. But that does show you applications have
been doing this for at least eight years.
--
Matthew Phillips
Durham
on 25 May 2013 Vince M Hudd wrote:
> I would be interested in knowing how far back this method goes - and in
> particular, who first implemented it. Mainly because, prior to the two
> examples given in this thread - ConvImgs and Locate - I had thought Alan's
> use of it was the first.
Impact version 3.27, in October 2005, introduced a little draggable directory
> I would be interested in knowing how far back this method goes - and in
> particular, who first implemented it. Mainly because, prior to the two
> examples given in this thread - ConvImgs and Locate - I had thought Alan's
> use of it was the first.
icon next to a writable icon where the backup path is set, which the user can
drag to a directory to set the backup location. If you drag it to the root
of the RAM disc, for example, then RAM::RamDisc0.$ appears in the writable
icon.
The backups that Impact produce entail creating a directory in the backup
location anyway, so the metaphor is not too bad, and the fact it is a small
directory icon, just to the right of the writable icon, helps to distinguish
it from a standard save box.
If you drag a directory from a Filer window to the writable icon, the full
pathname is placed in the writable icon. So users can do whichever feels
more natural. Much better to give the user both options, I think.
This doesn't answer your question, as to who first implemented
drag-and-not-drop, as I doubt anyone else has copied the idea from a fairly
obscure window in Impact! I am pretty sure I had seen the idea elsewhere
before I implemented it myself. But that does show you applications have
been doing this for at least eight years.
--
Matthew Phillips
Durham
Theo Markettos
May 26, 2013, 7:58:43 PM5/26/13
to
spampling <spam....@btinternet.com> wrote:
> I have a piece of paper that needs filing in the file over there - I will
> write a small note on it and the robo-secretary will put it in the selected
> location (unless the robo-secretary knows this is a critical document and
> it therefore needs to be with the other critical documents)
You write your Christmas cards and as you go you put them in your out-tray.
> I have a piece of paper that needs filing in the file over there - I will
> write a small note on it and the robo-secretary will put it in the selected
> location (unless the robo-secretary knows this is a critical document and
> it therefore needs to be with the other critical documents)
You then take the pile from your out-tray and go for a walk around the
village to deliver them all.
You don't write one card, deliver it, go home, write another card, deliver
that, and so on.
The latter is rather like the drag-save-install one app at a time that we
have at the moment. Perhaps we need a drag-and-drop equivalent of the
out-tray, to pick locations which aren't going to be used just yet.
Separating the location from the temporality of the action (ie do it now or
do it later).
Theo
spampling
May 27, 2013, 3:20:00 AM5/27/13
to
In article <lno*SH...@news.chiark.greenend.org.uk>, Theo Markettos
That was the model I was thinking of: many items with notes saying where
they go. In your example many cards with individual addresses, then
someone/something takes them away and files them/delivers them.
--
Steve Pampling
they go. In your example many cards with individual addresses, then
someone/something takes them away and files them/delivers them.
--
Steve Pampling
Vince M Hudd
May 27, 2013, 6:40:14 AM5/27/13
to
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> In message <mpro.mndbwa002...@softrock.co.uk>
> on 25 May 2013 Vince M Hudd wrote:
> > I would be interested in knowing how far back this method goes - and in
> > particular, who first implemented it. Mainly because, prior to the two
> > examples given in this thread - ConvImgs and Locate - I had thought
> > Alan's use of it was the first.
> Impact version 3.27, in October 2005, introduced a little draggable
> directory icon next to a writable icon where the backup path is set, which
> the user can drag to a directory to set the backup location. If you drag
> it to the root of the RAM disc, for example, then RAM::RamDisc0.$ appears
> in the writable icon.
I recently began using Impact via the Nut Pi package. ISTR seeing something
> In message <mpro.mndbwa002...@softrock.co.uk>
> on 25 May 2013 Vince M Hudd wrote:
> > I would be interested in knowing how far back this method goes - and in
> > particular, who first implemented it. Mainly because, prior to the two
> > examples given in this thread - ConvImgs and Locate - I had thought
> > Alan's use of it was the first.
> Impact version 3.27, in October 2005, introduced a little draggable
> directory icon next to a writable icon where the backup path is set, which
> the user can drag to a directory to set the backup location. If you drag
> it to the root of the RAM disc, for example, then RAM::RamDisc0.$ appears
> in the writable icon.
for configuring the backup location, which I didn't set at the time (my
existing backup strategy should be fine).
However, I've just loaded Impact to look at this and I can't find it. Is it
something that only appears when it's first run?
From your description, though, it sounds pretty much the same as how Alan's
doing it at the moment.
Which - because I don't think I've been entirely clear on this so far in
this thread - I really don't like at all. :)
> The backups that Impact produce entail creating a directory in the backup
> location anyway, so the metaphor is not too bad, and the fact it is a
> small directory icon, just to the right of the writable icon, helps to
> distinguish it from a standard save box.
appropriate to present something more akin to the normal drag and drop
behaviour:
The user types in a name for the backup directory in the writable icon (such
as DB_Backups), and drags the folder icon to a suitable location. The path
is updated to show the full path of DB_Backups, and a folder - cunningly
named DB_Backups - appears in the destination directory, where it was
dropped. Thereafter, Impact puts its backups in DB_Backups.
> If you drag a directory from a Filer window to the writable icon, the full
> pathname is placed in the writable icon. So users can do whichever feels
> more natural. Much better to give the user both options, I think.
and close my mind to the insanity of others. :)
> This doesn't answer your question, as to who first implemented
> drag-and-not-drop, as I doubt anyone else has copied the idea from a
> fairly obscure window in Impact! I am pretty sure I had seen the idea
> elsewhere before I implemented it myself. But that does show you
> applications have been doing this for at least eight years.
Vince M Hudd
May 27, 2013, 5:55:19 AM5/27/13
to
Martin Bazley <martin...@blueyonder.co.uk> wrote:
> The following bytes were arranged on 25 May 2013 by Vince M Hudd :
> > (And note that my original suggestion of dropping a pseudo-app wouldn't
> > be subject to this particular flaw - though that's only a suggestion
> > applicable to PackMan; other apps need other solutions, appropriate to
> > what they are not-dropping.)
> Your pseudo-app suggestion conflicts with one of the major changes which
> needs to be made to the package format, and indeed is part of the reason
> the window has been designed the way it is in the first place: the ability
> to install things which are *not* application directories.
Not necessarily a conflict, so much as an annoyance.
> The following bytes were arranged on 25 May 2013 by Vince M Hudd :
> > (And note that my original suggestion of dropping a pseudo-app wouldn't
> > be subject to this particular flaw - though that's only a suggestion
> > applicable to PackMan; other apps need other solutions, appropriate to
> > what they are not-dropping.)
> Your pseudo-app suggestion conflicts with one of the major changes which
> needs to be made to the package format, and indeed is part of the reason
> the window has been designed the way it is in the first place: the ability
> to install things which are *not* application directories.
With the chief point of the pseudo-app suggestion being that it turns drag
and not-drop into drag and drop, such that when you release, soemthing is
dropped and lands in whatever directory viewer was below, it and provides
instant visual feedback to users *where their attention is focused* that the
process has worked and that's where the item is to be installed.
(Instead of releasing, and the object falling into a hitherto unseen
wormhole between the mouse pointer and the directory viewer below it, and
the other end of this wormhole being the same location, but displaced in
time.)
So, when a file is dropped, a pseudo-app can be dropped in its place - with
the annoyance being that if the file lacked an exclamation mark at the start
of its name, the pseudo app would have one.
However, thinking about it now I realise that rather than a pseudo-app, a
file is all that's needed.
When I originally put forward this idea I suggested the pseudo-app so that,
if double-clicked, would invoke PackMan, which would inform the user that
the installation was not yet complete. I dismissed a file for the purpose
because I was thinking of a registered filetype for PackMan (and other
package managers, should any ever be written[1]) - which I felt would be a
waste of a filetype.
In fact, though, it could always be a file: Just an obey file, named for
whatever was dragged. Installing an app called !EggOnToast? Drop an obey
file called !EggOnToast. Installing a BASIC program[2] called NotAnApp? Drop
an obey file called NotAnApp. Etc.
The contents of the obey file would be the same in every case - it would
cause PackMan to inform the user as above.
There is a flaw with this connected with what I now understand (I think) are
Alan's intentions: That the stuff a user has selected for installation is
only valid in that session. If the user quits PackMan without proceeding
with the installation, the to-be-installed list is forgotten.
With the file (or pseudo-app), the assumption I made when I suggested that
solution was that if you quit PackMan without having proceeded, the next
time you loaded PackMan those packages would still be listed, ready for
installtion to go ahead.
I'd prefer it if PackMan maintained the list, TBH, but if not it would have
to clean up after itself when quit - those files removed. And, of course,
they would be left there in problem situations, such as a power failure.
Another flaw, arguably, is that the filetype would be wrong - but last I
checked, the moon wasn't available on sticks.
[1] I'm ignoring RiscPkg, because when I think of it the words "dead" and
"dodo" also come to mind.
[2] When the package format is appropriately fixed, obviously. :)
Vince M Hudd
May 27, 2013, 5:09:26 AM5/27/13
to
Tim Hill <t...@invalid.org.uk> wrote:
> In article <mpro.mndbwa002...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> > A question, though: Given that the path can be updated by dragging the
> > folder icon from the pseudo save dialogue, *or* by dragging a folder
> > icon onto the path itself, why does it need to be writable? At what
> > point do you envisage a user putting the cursor in that icon and
> > modifying it?
> Perhaps it doesn't need to be writable, so long as it is near the drag
> icon/drop target and clearly shows the path selected or chosen by default
> (in different colours?!).
Chris has given a perfectly good reason for it to be writable that I hadn't
> In article <mpro.mndbwa002...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
> > A question, though: Given that the path can be updated by dragging the
> > folder icon from the pseudo save dialogue, *or* by dragging a folder
> > icon onto the path itself, why does it need to be writable? At what
> > point do you envisage a user putting the cursor in that icon and
> > modifying it?
> Perhaps it doesn't need to be writable, so long as it is near the drag
> icon/drop target and clearly shows the path selected or chosen by default
> (in different colours?!).
considered.
Note: While in the Brecons yesterday, I pondered this subject, and -
ignoring *possible* alternatives, and just considering the examples I've
seen in action - I've decided I prefer Chris's implementation. (Prefer in
this case meaning "I still don't like drag and not-drop, but if it must be
done, then something along these lines is bearable.")
I'll expand on this in another post.
I'm still going to reply to some of your comments, though. :)
> A writable icon may be useful:
> 0. Cut'n'paste
> Imagine leaving an email note for another user: "I have installed
> !app in its default folder. Can't tell you where it is because the
> installer app wouldn't let me Copy the path. Happy hunting."
copied.
> 1. Because I dragged an object from the root directory to set the path and
> actually wanted to set it to the root of a device.
possibility that has already been discussed.
[...]
> Qs. If I type directory names which do not exist into the path, will they
> be created? Will each path be parsed for validity? Not having a writable
> icon potentially saves trouble as only valid paths can be dragged.
> (Vince, this has made me remember that there have been times when I used
> to grumble to myself and wished that WebChange had a writable icon for the
> path, so as to get at the directory I already have open in front of me.
> From experience with other apps, I expect to be able to drag anything from
> the folder and then delete the leafname. I have instead learnt not to do
> that.)
<mpro.mnd4om004...@softrock.co.uk> I said, responding to your
tongue in cheek suggestion that I add drag and not-drop to WebChange for
setting the path:
----8<----
after Theo suggested a key-modified drag as a means to say "the parent of
this" rather than just "this", I did add that to my to-do list.
----8<----
this" rather than just "this", I did add that to my to-do list.
Another possibility (if you've only realised you wanted the parent after
performing the drag) could be a small button to truncate the path by one
level. Or, perhaps, making the icon writable to allow that to be done
manually.
[...]
Vince M Hudd
May 27, 2013, 4:51:52 AM5/27/13
to
spampling <spam....@btinternet.com> wrote:
> > I have a piece of paper on my desk. I'm going to file it in this file
> > right here...
> > WOAH! WAIT! WHAT HAPPENED?
> > Instead of ending up in the file, the paper is still on my desk, but now
> > it has the name of the file on it!
> I have a piece of paper that needs filing in the file over there - I will
> write a small note on it and the robo-secretary will put it in the
> selected location
Except that you are writing the small note on it through the action of
> > I have a piece of paper on my desk. I'm going to file it in this file
> > right here...
> > WOAH! WAIT! WHAT HAPPENED?
> > Instead of ending up in the file, the paper is still on my desk, but now
> > it has the name of the file on it!
> I have a piece of paper that needs filing in the file over there - I will
> write a small note on it and the robo-secretary will put it in the
> selected location
taking it over to the file and releasing it there, whereupon it lands back
where it started with the note on it.
My analogy was closer to the mark in terms of what happens with this drag
and not-drop.
Writing a note on the piece of paper as an instruction of where to file it
would actually be more akin to making use of the fact that the path is in a
writable icon, and just typing in the destination. (Which you could do, of
course, but isn't the aspect of this facility that I'm commenting on).
> (unless the robo-secretary knows this is a critical document and it
> therefore needs to be with the other critical documents)
file and places it therein, to avoid it returning to its original location.
Vince M Hudd
May 27, 2013, 7:01:33 AM5/27/13
to
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Perhaps we need a drag-and-drop equivalent of the out-tray, to pick
> locations which aren't going to be used just yet. Separating the location
> from the temporality of the action (ie do it now or do it later).
Agreed.
> Perhaps we need a drag-and-drop equivalent of the out-tray, to pick
> locations which aren't going to be used just yet. Separating the location
> from the temporality of the action (ie do it now or do it later).
As I said in another post, of the drag and not-drop implementations I've now
seen, I prefer the one by Chris Johnson in ConvImgs.
The reason - and by far the biggest and best advantage it has (apparently
shared by some others, for example Impact according to Matthew's
description) - is that it works both ways:
* It offers drag and not-drop, whereby you drag the icon to a location and
release but not-drop it, for those who have a preference for miming an
action to be carried out later.
* And it offers drag and drop, whereby you drag a destination folder onto
the path and, upon release, it drops to immediate effect *where the user's
attention is focused*, causing the displayed path to be updated.
The drag and not-drop implementation is done in a way that does set it apart
slightly from normal drag and drop operations by presenting the draggable
icon in a small, separate window - whereas a normal save dialogue presents
both the draggable and writable icons in the same window, which - to me, at
least, makes any example where an icon can be dragged to a destination from
the same window that contains a writable path/name seem more like it should
work like a normal save.
I also notice, having just checked because it didn't register with me the
other day, that the title for the pop-up window containing the draggable
icon is "Set path".
I think, if developers are going to use drag and not-drop, then something
like the method Chris has used might be preferable.
druck
May 27, 2013, 11:39:46 AM5/27/13
to
On 26/05/2013 14:30, Martin Bazley wrote:
> The following bytes were arranged on 25 May 2013 by druck :
>
>> On 23/05/2013 19:27, Martin Bazley wrote:
>>> Unfortunately, this type of user interface design has one
>>> major drawback which its proponents have never adequately answered:
>>> what happens if you want to install to the root of a disc? What do
>>> you drag then?
>>
>> The drive icon on the iconbar. Some, but not all, filers support this.
>
> You can drag *to* the drive icon. You most certainly cannot drag the
> drive icon *itself* to the window, which was the problem with the method
> under discussion. I think you've got yourself confused.
Sorry, meant what you said, but used the wrong words.
> The following bytes were arranged on 25 May 2013 by druck :
>
>> On 23/05/2013 19:27, Martin Bazley wrote:
>>> Unfortunately, this type of user interface design has one
>>> major drawback which its proponents have never adequately answered:
>>> what happens if you want to install to the root of a disc? What do
>>> you drag then?
>>
>> The drive icon on the iconbar. Some, but not all, filers support this.
>
> You can drag *to* the drive icon. You most certainly cannot drag the
> drive icon *itself* to the window, which was the problem with the method
> under discussion. I think you've got yourself confused.
---druck
spampling
May 27, 2013, 10:51:59 AM5/27/13
to
In article <mpro.mng8mg00m...@softrock.co.uk>, Vince M Hudd
have a clue and puts it where it really belongs rather than where you tried
to put it.
* You said "she" so I now have a picture of a robot with a tweed skirt and
horn-rim glasses.
--
Steve Pampling
<vin...@softrock.co.uk> wrote:
> > (unless the robo-secretary knows this is a critical document and it
> > therefore needs to be with the other critical documents)
> At which point, she catches the piece of paper when you release it over
> the file and places it therein, to avoid it returning to its original
> location.
Actually the robo-secretary realises that (like most bosses) you don't
> > (unless the robo-secretary knows this is a critical document and it
> > therefore needs to be with the other critical documents)
> At which point, she catches the piece of paper when you release it over
> the file and places it therein, to avoid it returning to its original
> location.
have a clue and puts it where it really belongs rather than where you tried
to put it.
* You said "she" so I now have a picture of a robot with a tweed skirt and
horn-rim glasses.
--
Steve Pampling
Matthew Phillips
May 27, 2013, 5:18:12 PM5/27/13
to
In message <mpro.mngdn200q...@softrock.co.uk>
on 27 May 2013 Vince M Hudd wrote:
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > Impact version 3.27, in October 2005, introduced a little draggable
> > directory icon next to a writable icon where the backup path is set,
> > which the user can drag to a directory to set the backup location. If
> > you drag it to the root of the RAM disc, for example, then
> > RAM::RamDisc0.$ appears in the writable icon.
>
> I recently began using Impact via the Nut Pi package. ISTR seeing something
> for configuring the backup location, which I didn't set at the time (my
> existing backup strategy should be fine).
Yes, the Impact backup tool is a bit of a relic, really, from when people
just backed up a few important things onto floppy discs, if they backed up
anything at all, that is. It allows you to define frequency of backup, and
how many previous versions to keep, and compresses the files when backing up,
so it's quite friendly. The redesign in version 3.27 replaced a dialogue box
which tried to perform masses of different functions with far too few icons.
> However, I've just loaded Impact to look at this and I can't find it. Is it
> something that only appears when it's first run?
No, it's a per-database configuration, and to do it you have to add the
backup tool to the database's toolbar (edit the card design, double-click the
toolbar area to open the palette of tools).
> > The backups that Impact produce entail creating a directory in the backup
> > location anyway, so the metaphor is not too bad, and the fact it is a
> > small directory icon, just to the right of the writable icon, helps to
> > distinguish it from a standard save box.
>
> I would have thought, though, that in this case it would perhaps be more
> appropriate to present something more akin to the normal drag and drop
> behaviour:
>
> The user types in a name for the backup directory in the writable icon
> (such as DB_Backups), and drags the folder icon to a suitable location. The
> path is updated to show the full path of DB_Backups, and a folder -
> cunningly named DB_Backups - appears in the destination directory, where it
> was dropped. Thereafter, Impact puts its backups in DB_Backups.
That would be quite logical, and perhaps I should change things, but....
The default is for the path icon to have "<Impact$BackupDir>" in it, which
will, generally, point to a directory called "BackupData" which sits
alongside !Impact itself and the SampleData na dUserData directories.
Within BackupData, any databases which are backed up will each have a
directory named the same as the name of the database, but with a different
structure further in than the equivalently-named directory in UserData.
So the expectation is for the same backup path to be set for several
different databases.
You're correct, that the tool could look more like a standard Save As
dialogue, but as the user would often already have a directory to use, it
seemed to make more sense to drop something inside the directory or disc root
that was wanted. We don't want to create something and give the user the
impression that a backup has actually been produced, and also if the user
hand-edits the path, or drags a directory *to* the window to set the path,
the new setting does not take effect until the user clicks on "Save
settings". Having the setting change and be saved on drag and drop could be
awkward.
I'm sure you'll just say that this awkwardness proves your point! I just
tried to let users go with whichever method feels more natural to them.
--
Matthew Phillips
Durham
on 27 May 2013 Vince M Hudd wrote:
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > Impact version 3.27, in October 2005, introduced a little draggable
> > directory icon next to a writable icon where the backup path is set,
> > which the user can drag to a directory to set the backup location. If
> > you drag it to the root of the RAM disc, for example, then
> > RAM::RamDisc0.$ appears in the writable icon.
>
> I recently began using Impact via the Nut Pi package. ISTR seeing something
> for configuring the backup location, which I didn't set at the time (my
> existing backup strategy should be fine).
just backed up a few important things onto floppy discs, if they backed up
anything at all, that is. It allows you to define frequency of backup, and
how many previous versions to keep, and compresses the files when backing up,
so it's quite friendly. The redesign in version 3.27 replaced a dialogue box
which tried to perform masses of different functions with far too few icons.
> However, I've just loaded Impact to look at this and I can't find it. Is it
> something that only appears when it's first run?
backup tool to the database's toolbar (edit the card design, double-click the
toolbar area to open the palette of tools).
> > The backups that Impact produce entail creating a directory in the backup
> > location anyway, so the metaphor is not too bad, and the fact it is a
> > small directory icon, just to the right of the writable icon, helps to
> > distinguish it from a standard save box.
>
> I would have thought, though, that in this case it would perhaps be more
> appropriate to present something more akin to the normal drag and drop
> behaviour:
>
> The user types in a name for the backup directory in the writable icon
> (such as DB_Backups), and drags the folder icon to a suitable location. The
> path is updated to show the full path of DB_Backups, and a folder -
> cunningly named DB_Backups - appears in the destination directory, where it
> was dropped. Thereafter, Impact puts its backups in DB_Backups.
The default is for the path icon to have "<Impact$BackupDir>" in it, which
will, generally, point to a directory called "BackupData" which sits
alongside !Impact itself and the SampleData na dUserData directories.
Within BackupData, any databases which are backed up will each have a
directory named the same as the name of the database, but with a different
structure further in than the equivalently-named directory in UserData.
So the expectation is for the same backup path to be set for several
different databases.
You're correct, that the tool could look more like a standard Save As
dialogue, but as the user would often already have a directory to use, it
seemed to make more sense to drop something inside the directory or disc root
that was wanted. We don't want to create something and give the user the
impression that a backup has actually been produced, and also if the user
hand-edits the path, or drags a directory *to* the window to set the path,
the new setting does not take effect until the user clicks on "Save
settings". Having the setting change and be saved on drag and drop could be
awkward.
I'm sure you'll just say that this awkwardness proves your point! I just
tried to let users go with whichever method feels more natural to them.
--
Matthew Phillips
Durham
charles
May 28, 2013, 2:56:05 AM5/28/13
to
In article <5351cde741...@btinternet.com>, spampling
I am reminded of the John Cleese' training video on the subject of filing.
The secretary who did the filing was away and the bosses needed to find a
particular letter. They looked under the name of the company, the name of
the individual and even the product name - failure. When the secretary
returned, they asked her where it was. "Easy, it's a letter, so it's filed
under L"
--
From KT24
Using a RISC OS computer running v5.18
The secretary who did the filing was away and the bosses needed to find a
particular letter. They looked under the name of the company, the name of
the individual and even the product name - failure. When the secretary
returned, they asked her where it was. "Easy, it's a letter, so it's filed
under L"
--
From KT24
Using a RISC OS computer running v5.18
Chris Evans
May 29, 2013, 9:53:18 AM5/29/13
to
In article <mpro.mnd1m2002...@softrock.co.uk>, Vince M Hudd
> > In article <mpro.mncx15004...@softrock.co.uk>, Vince M Hudd
> > <vin...@softrock.co.uk> wrote:
>
> > [Snip]
>
> > > > Still struggling to find these concepts counter-intuitive.
>
> > > Still struggling to find the idea of drag and not-drop anything but.
>
> > I suppose it is just that other instances of 'drag to set a path' exist
>
> But not in anything I use AFAIK
Impression and quite a few other Apps that have an installer use 'drag to
set a path'. So may be not in daily use but I suspect you will have used it
in the past.
In an installation process something appearing in the destination directory
viewer would be I'm sure we all? agree a bad idea.
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
> > In article <mpro.mncx15004...@softrock.co.uk>, Vince M Hudd
> > <vin...@softrock.co.uk> wrote:
>
> > [Snip]
>
> > > > Still struggling to find these concepts counter-intuitive.
>
> > > Still struggling to find the idea of drag and not-drop anything but.
>
> > I suppose it is just that other instances of 'drag to set a path' exist
>
> But not in anything I use AFAIK
Impression and quite a few other Apps that have an installer use 'drag to
set a path'. So may be not in daily use but I suspect you will have used it
in the past.
In an installation process something appearing in the destination directory
viewer would be I'm sure we all? agree a bad idea.
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
Vince M Hudd
May 29, 2013, 2:54:50 PM5/29/13
to
spampling <spam....@btinternet.com> wrote:
[...]
> * You said "she" so I now have a picture of a robot with a tweed skirt and
> horn-rim glasses.
This thread just got exciting. ;)
[...]
> * You said "she" so I now have a picture of a robot with a tweed skirt and
> horn-rim glasses.
Vince M Hudd
May 29, 2013, 3:00:48 PM5/29/13
to
Chris Evans <ch...@cjemicros.co.uk> wrote:
> In article <mpro.mnd1m2002...@softrock.co.uk>, Vince M Hudd
> <URL:mailto:vin...@softrock.co.uk> wrote:
[Drag and not-drop goes back a way, apparently]
> In article <mpro.mnd1m2002...@softrock.co.uk>, Vince M Hudd
> <URL:mailto:vin...@softrock.co.uk> wrote:
> > But not in anything I use AFAIK
> Impression and quite a few other Apps that have an installer use 'drag to
> set a path'. So may be not in daily use but I suspect you will have used
> it in the past.
Impression's installer, though, since I've never had Impression!)
If I have used such an installer, though, it would have been a *very* long
time ago, when I gave a lot less thought to such matters.
> In an installation process something appearing in the destination
> directory viewer would be I'm sure we all? agree a bad idea.
suggested that it *could* put something in the directory viewer - or,
preferably, allow a destination folder to be dragged onto it to set the path
that way. Any installer could adopt a similar approach.
Vince M Hudd
May 29, 2013, 3:24:22 PM5/29/13
to
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> In message <mpro.mngdn200q...@softrock.co.uk>
> on 27 May 2013 Vince M Hudd wrote:
[...]
> In message <mpro.mngdn200q...@softrock.co.uk>
> on 27 May 2013 Vince M Hudd wrote:
> > However, I've just loaded Impact to look at this and I can't find it. Is
> > it something that only appears when it's first run?
> No, it's a per-database configuration, and to do it you have to add the
> backup tool to the database's toolbar (edit the card design, double-click
> the toolbar area to open the palette of tools).
icons to decide which ones were of most use to me for the database I
created.
[...]
> We don't want to create something and give the user the impression that a
> backup has actually been produced, and also if the user hand-edits the
> path, or drags a directory *to* the window to set the path, the new
> setting does not take effect until the user clicks on "Save settings".
> Having the setting change and be saved on drag and drop could be awkward.
part of your explanation, or similar, when you point out a flaw ;) the way
I'd handle that, I think, is for the drop to invoke a dialogue asking the
user if they want to carry out a backup now to the desired location or
merely set the location.
In this instance, the visual feedback would be provided by that dialogue -
even if they then said to only set the location, and not actually backup at
that moment.
Alternatively, a tick box in the dialogue that serves the same purpose as
the dialogue would: With "backup as soon as the location is set" (or
whatever the wording could be) ticked, when the folder is released, the
backup would happen.
But failing either, if I understood you correctly, users can drag a folder
onto the path - so if ever I was to use that feature, that's the way I'd do
it, thus allowing me to use things in what I percieve as a logical way while
continuing mentally block out the topsy turvy approach.
I wish this whole subject had come up before 1st April, though. I'd have
been inclined to include drag and not-drop as a double-bluff joke in the
RISC OS Rainbow piece on RISCOSitory.
> I'm sure you'll just say that this awkwardness proves your point!
[...]
spampling
May 30, 2013, 2:45:45 AM5/30/13
to
In article <mpro.mnkpve00m...@softrock.co.uk>, Vince M Hudd
their speciality may be useful.
CV2 2TE
--
Steve Pampling
<vin...@softrock.co.uk> wrote:
> spampling <spam....@btinternet.com> wrote:
> [...]
> > * You said "she" so I now have a picture of a robot with a tweed skirt
> > and horn-rim glasses.
> This thread just got exciting. ;)
Hmmm, the front end of our site has a building from a different Trust,
> spampling <spam....@btinternet.com> wrote:
> [...]
> > * You said "she" so I now have a picture of a robot with a tweed skirt
> > and horn-rim glasses.
> This thread just got exciting. ;)
their speciality may be useful.
CV2 2TE
--
Steve Pampling
Vince M Hudd
May 30, 2013, 7:03:58 AM5/30/13
to
Hmm. I notice the signs point to a drop off zone, but there isn't a not-drop
off zone. (Which would be where you get the taxi driver to take you, but not
drop you off, so that he knows where to take you when you do actually need
to go there.) :p
Chris Evans
May 30, 2013, 7:28:46 AM5/30/13
to
In article <mpro.mnkq5c00m...@softrock.co.uk>, Vince M Hudd
> If I have used such an installer, though, it would have been a *very* long
> time ago, when I gave a lot less thought to such matters.
>
> > In an installation process something appearing in the destination
> > directory viewer would be I'm sure we all? agree a bad idea.
>
> No, we don't.
Sorry I think I didn't explain myself fully.
I'm meaning that when you drag something to a destination directory viewer
to set a path nothing should at that time appear in the directory otherwise
people will think the installation has happened.
I'm not sure if you are suggesting below something should appear at that
point if so it seems a recipe for confusion!
> A package manager is a type of installer, and I've already
> suggested that it *could* put something in the directory viewer - or,
> preferably, allow a destination folder to be dragged onto it to set the path
> that way. Any installer could adopt a similar approach.
Dragging to the destination directory viewer is to my mind the most
intuative and in keeping with most RISC OS drag actions.
<URL:mailto:vin...@softrock.co.uk> wrote:
> Chris Evans <ch...@cjemicros.co.uk> wrote:
> > In article <mpro.mnd1m2002...@softrock.co.uk>, Vince M Hudd
> > <URL:mailto:vin...@softrock.co.uk> wrote:
>
> [Drag and not-drop goes back a way, apparently]
>
> > > But not in anything I use AFAIK
>
> > Impression and quite a few other Apps that have an installer use 'drag to
> > set a path'. So may be not in daily use but I suspect you will have used
> > it in the past.
>
> I don't remember ever having done so, but it's possible. (Certainly not with
> Impression's installer, though, since I've never had Impression!)
Photodesk (and I think Artworks installers) use 'drag to set a path'
> Chris Evans <ch...@cjemicros.co.uk> wrote:
> > In article <mpro.mnd1m2002...@softrock.co.uk>, Vince M Hudd
> > <URL:mailto:vin...@softrock.co.uk> wrote:
>
> [Drag and not-drop goes back a way, apparently]
>
> > > But not in anything I use AFAIK
>
> > Impression and quite a few other Apps that have an installer use 'drag to
> > set a path'. So may be not in daily use but I suspect you will have used
> > it in the past.
>
> I don't remember ever having done so, but it's possible. (Certainly not with
> Impression's installer, though, since I've never had Impression!)
> If I have used such an installer, though, it would have been a *very* long
> time ago, when I gave a lot less thought to such matters.
>
> > In an installation process something appearing in the destination
> > directory viewer would be I'm sure we all? agree a bad idea.
>
> No, we don't.
I'm meaning that when you drag something to a destination directory viewer
to set a path nothing should at that time appear in the directory otherwise
people will think the installation has happened.
I'm not sure if you are suggesting below something should appear at that
point if so it seems a recipe for confusion!
> A package manager is a type of installer, and I've already
> suggested that it *could* put something in the directory viewer - or,
> preferably, allow a destination folder to be dragged onto it to set the path
> that way. Any installer could adopt a similar approach.
intuative and in keeping with most RISC OS drag actions.
spampling
May 30, 2013, 12:32:10 PM5/30/13
to
In article <mpro.mnlyqm003...@softrock.co.uk>, Vince M Hudd
residents. All have, er, personality issues...
> Hmm. I notice the signs point to a drop off zone, but there isn't a
> not-drop off zone. (Which would be where you get the taxi driver to take
> you, but not drop you off, so that he knows where to take you when you
> do actually need to go there.) :p
Joys of PFI, there may be signs but the actual facility may not live up to
expectations.
--
Steve Pampling
<vin...@softrock.co.uk> wrote:
> spampling <spam....@btinternet.com> wrote:
> > In article <mpro.mnkpve00m...@softrock.co.uk>, Vince M
> > Hudd <vin...@softrock.co.uk> wrote:
> > > spampling <spam....@btinternet.com> wrote:
> > > [...]
> > > > * You said "she" so I now have a picture of a robot with a tweed
> > > > skirt and horn-rim glasses.
>
> > > This thread just got exciting. ;)
>
> > Hmmm, the front end of our site has a building from a different Trust,
> > their speciality may be useful. CV2 2TE
> "Adult Services" ? Is that a modern PC name for an STI clinic? :)
The call the unit The Caludon Centre and it deals with both day case and
> spampling <spam....@btinternet.com> wrote:
> > In article <mpro.mnkpve00m...@softrock.co.uk>, Vince M
> > Hudd <vin...@softrock.co.uk> wrote:
> > > spampling <spam....@btinternet.com> wrote:
> > > [...]
> > > > * You said "she" so I now have a picture of a robot with a tweed
> > > > skirt and horn-rim glasses.
>
> > > This thread just got exciting. ;)
>
> > Hmmm, the front end of our site has a building from a different Trust,
> > their speciality may be useful. CV2 2TE
> "Adult Services" ? Is that a modern PC name for an STI clinic? :)
residents. All have, er, personality issues...
> Hmm. I notice the signs point to a drop off zone, but there isn't a
> not-drop off zone. (Which would be where you get the taxi driver to take
> you, but not drop you off, so that he knows where to take you when you
> do actually need to go there.) :p
expectations.
--
Steve Pampling
Stuart
May 30, 2013, 5:02:21 PM5/30/13
to
In article <53540709f7...@btinternet.com>,
"client" a little before he retired. He was off work for several weeks.
--
Stuart Winsor
Midlands RISC OS and Raspberry pi show, 13th July 2013
http://www.mug.riscos.org/show13/MUGshow.html
spampling <spam....@btinternet.com> wrote:
> The call the unit The Caludon Centre and it deals with both day case and
> residents. All have, er, personality issues...
A friend of mine used to work there, he got seriously beaten up by a
> The call the unit The Caludon Centre and it deals with both day case and
> residents. All have, er, personality issues...
"client" a little before he retired. He was off work for several weeks.
--
Stuart Winsor
Midlands RISC OS and Raspberry pi show, 13th July 2013
http://www.mug.riscos.org/show13/MUGshow.html
spampling
Jun 1, 2013, 8:53:46 AM6/1/13
to
In article <53541fc6...@argonet.co.uk>, Stuart
back in. In one case about a year ago they drove through the front doors,
through the controlled access doors and wedged in the bend in the corridor.
I made getting in/out of the pharmacy a bit awkward until the car was
moved.
They had a night not at home - they were in a police cell. Still didn't
get re-admitted.
--
Steve Pampling
<Spa...@argonet.co.uk> wrote:
> In article <53540709f7...@btinternet.com>, spampling
> <spam....@btinternet.com> wrote:
> > The call the unit The Caludon Centre and it deals with both day case
> > and residents. All have, er, personality issues...
> A friend of mine used to work there, he got seriously beaten up by a
> "client" a little before he retired. He was off work for several weeks.
They also have "clients" that don't like being discharged and try to get
> In article <53540709f7...@btinternet.com>, spampling
> <spam....@btinternet.com> wrote:
> > The call the unit The Caludon Centre and it deals with both day case
> > and residents. All have, er, personality issues...
> A friend of mine used to work there, he got seriously beaten up by a
> "client" a little before he retired. He was off work for several weeks.
back in. In one case about a year ago they drove through the front doors,
through the controlled access doors and wedged in the bend in the corridor.
I made getting in/out of the pharmacy a bit awkward until the car was
moved.
They had a night not at home - they were in a police cell. Still didn't
get re-admitted.
--
Steve Pampling
Tim Hill
Jun 1, 2013, 12:04:26 PM6/1/13
to
In article <ant30114...@client.cjemicros.co.uk>, Chris Evans
<ch...@cjemicros.co.uk> wrote:
[Snip]
> Dragging to the destination directory viewer is to my mind the most
> intuative and in keeping with most RISC OS drag actions.
It may be what we are used to but Vince has a pedantic point with his
drag-and-drop-doesn't-drop as nothing appears at the drop location (on
the set path) until later in a multi-install situation. A placeholder
file which appears at the drop location would at least give a visual
indication that something has happened /at the drop point/. I tend to
agree as any text icons which display set paths are rarely long enough to
display many entire paths without scrolling and it's easy to not see them
changing when your eyes are on the object you are dropping in a viewer
/where nothing happens/.
Just because we are used to doing something a particular way (me too!)
does not make it right or logical for new users. Dragging a directory to
a target to set a destination path makes more logical sense because the
point at which you drop it changes immediately to show the set path (or
it should).
Programs such as !Locate offer both options so anyone who doesn't like
the drag in one direction can use the other. It may be no surprise that
Vince's WebChange only implements the 'drag directory to target' method
which is perfectly intuitive (even if he hasn't yet circumvented the
imagined 'problem' of anyone who wants to set the path to the root of a
device!).
--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/
<ch...@cjemicros.co.uk> wrote:
[Snip]
> Dragging to the destination directory viewer is to my mind the most
> intuative and in keeping with most RISC OS drag actions.
drag-and-drop-doesn't-drop as nothing appears at the drop location (on
the set path) until later in a multi-install situation. A placeholder
file which appears at the drop location would at least give a visual
indication that something has happened /at the drop point/. I tend to
agree as any text icons which display set paths are rarely long enough to
display many entire paths without scrolling and it's easy to not see them
changing when your eyes are on the object you are dropping in a viewer
/where nothing happens/.
Just because we are used to doing something a particular way (me too!)
does not make it right or logical for new users. Dragging a directory to
a target to set a destination path makes more logical sense because the
point at which you drop it changes immediately to show the set path (or
it should).
Programs such as !Locate offer both options so anyone who doesn't like
the drag in one direction can use the other. It may be no surprise that
Vince's WebChange only implements the 'drag directory to target' method
which is perfectly intuitive (even if he hasn't yet circumvented the
imagined 'problem' of anyone who wants to set the path to the root of a
device!).
--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/
spampling
Jun 2, 2013, 5:32:50 AM6/2/13
to
In article <53550c...@invalid.org.uk>,
Drag and drop as expected.
Visibly has dropped an item so no confusion about where it is going.
All newbies will expect a PeeCee style confirmation button - which already
exists in the installer.
--
Steve Pampling
Tim Hill <t...@invalid.org.uk> wrote:
> It may be what we are used to but Vince has a pedantic point with his
> drag-and-drop-doesn't-drop as nothing appears at the drop location (on
> the set path) until later in a multi-install situation. A placeholder
> file which appears at the drop location would at least give a visual
> indication that something has happened /at the drop point/.
Excellent idea:
> It may be what we are used to but Vince has a pedantic point with his
> drag-and-drop-doesn't-drop as nothing appears at the drop location (on
> the set path) until later in a multi-install situation. A placeholder
> file which appears at the drop location would at least give a visual
> indication that something has happened /at the drop point/.
Drag and drop as expected.
Visibly has dropped an item so no confusion about where it is going.
All newbies will expect a PeeCee style confirmation button - which already
exists in the installer.
--
Steve Pampling
Vince M Hudd
Jun 2, 2013, 3:10:55 PM6/2/13
to
spampling <spam....@btinternet.com> wrote:
> In article <53550c...@invalid.org.uk>,
> Tim Hill <t...@invalid.org.uk> wrote:
> > It may be what we are used to but Vince has a pedantic point with his
> > drag-and-drop-doesn't-drop as nothing appears at the drop location (on
> > the set path) until later in a multi-install situation. A placeholder
> > file which appears at the drop location would at least give a visual
> > indication that something has happened /at the drop point/.
> Excellent idea:
> Drag and drop as expected.
> Visibly has dropped an item so no confusion about where it is going.
Which is what I suggested *very early* in this thread.
> In article <53550c...@invalid.org.uk>,
> Tim Hill <t...@invalid.org.uk> wrote:
> > It may be what we are used to but Vince has a pedantic point with his
> > drag-and-drop-doesn't-drop as nothing appears at the drop location (on
> > the set path) until later in a multi-install situation. A placeholder
> > file which appears at the drop location would at least give a visual
> > indication that something has happened /at the drop point/.
> Excellent idea:
> Drag and drop as expected.
> Visibly has dropped an item so no confusion about where it is going.
And then I said it again.
And I think I might have said it at least one more time after that, possibly
twice. Or more.
> All newbies will expect a PeeCee style confirmation button - which already
> exists in the installer.
fuss about this. We harp on about how intuitive our drag and drop is, and
then we completely muddy that by adding drag and not-drop just to confuse
them.
spampling
Jun 3, 2013, 2:51:03 AM6/3/13
to
In article <mpro.mns5a700n...@softrock.co.uk>,
Oh, and robo-secretary has to refuse to put system files in the wrong
place. So that's a drag and can't let go.
Oh and weren't you advocating dragging the directory to the package
manager, or am I losing the plot?
--
Steve Pampling
Vince M Hudd <vin...@softrock.co.uk> wrote:
> Which is what I suggested *very early* in this thread.
> And then I said it again.
Nope you wanted the packaged item not a marker file.
> And then I said it again.
Oh, and robo-secretary has to refuse to put system files in the wrong
place. So that's a drag and can't let go.
Oh and weren't you advocating dragging the directory to the package
manager, or am I losing the plot?
--
Steve Pampling
Vince M Hudd
Jun 3, 2013, 4:37:27 AM6/3/13
to
spampling <spam....@btinternet.com> wrote:
> In article <mpro.mns5a700n...@softrock.co.uk>,
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > Which is what I suggested *very early* in this thread.
> > And then I said it again.
> Nope you wanted the packaged item not a marker file.
s/wanted/suggested/
> In article <mpro.mns5a700n...@softrock.co.uk>,
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > Which is what I suggested *very early* in this thread.
> > And then I said it again.
> Nope you wanted the packaged item not a marker file.
And the thing with suggestions? There can be more than one of them.
The only thing I *don't* want is drag and not-drop - at least not as the
only option, so I can do something logical and be oblivious to what the
crazy folk are doing.
For the sake of setting the record straight on the specific subject of
dropping something into the destination, and ignoring other suggestions I've
made such as dragging the destination folder onto the path icon, the
following are the one where I "wanted" what you said above, followed by
the initial post in which I suggested dropping something and the subsequent
posts where I've built on that suggestion. There are other posts in which I
re-iterated the idea.
On 18/5/2013, in Message-ID: <mpro.mn08oe00i...@softrock.co.uk>
I did say that the installation should commence immediately "for packages
containing just one item that can be dragged". And in the next two
paragraphs, I suggested that for packages with more than one item that can
be dragged, there could be an option to have just one drag and drop to cover
all items - which would, again, commence the installation immediately.
I didn't make a big fuss over drag and not-drop in that post except, having
not given any real thought to other alternative solutions, and not realising
that Alan was providing a way to install more than one package at a time -
something that PackMan currently doesn't do, and which a package manager
*should* do - begrudgingly say it feels wrong but makes sense for packages
with more than one dragable under the circumstances.
On 20/5/2013, in Message-ID: <mpro.mn47xq008...@softrock.co.uk>
I suggested dropping a pseudo-application in response to each drag and drop
(so that they were not not-drops). The idea being that the pseudo
application would invoke PackMan, causing it to pop up a message to say
installation was incomplete and give the user the option to proceed. (At
this stage I dismissed the idea of a file for completely the wrong reason -
a consequence of not having thought it through properly.)
On 23/5/2013, in Message-ID: <mpro.mn9ids001...@softrock.co.uk>
I added that, IMO, the style guide should [have] mandate[d] that drag and
not-drop is verboten.
In reply to Tim on 25/5/2013, in Message-ID:
<mpro.mnd1m2002...@softrock.co.uk> I quoted myself from
Message-ID: <mpro.mn47xq008...@softrock.co.uk> above - where I
made the pseudo-app suggestion - in response to Tim suggested the same thing
but using different words ("a skeleton object").
On 27/5/2013, in Message-ID: <mpro.mngbk700o...@softrock.co.uk>
- in reply to Martin's point that a pseudo-app wouldn't be a good solution
if what's being installed is a file (which the packaging format doesn't
currently allow) - I went back to my dismissal of dropping a file, and
concluded that I was wrong to do so, and that a file (specifically, an Obey
file) was what could/should be dropped and appear in the drop-target.
Grahame Parish
Jun 3, 2013, 6:30:50 AM6/3/13
to
trying to find it! I don't know how Alan is supposed to code this so
that it will work with everyone's personal view of how it should be done!
Pseudo files/apps being dropped is a bad idea because it gives a
misleading impression of the action being completed and means it all has
to be tidied up if the user aborts/cancels/has a power failure/etc.
It's also non-RISC OS to drop a file/app into a folder that isn't the
file/app that the user is intending - this is not Windows. We also end
up from the suggestions above of having different actions carried
depending if it is a single install or a multiple install. This would
confuse many seasoned users, let alone newbies.
The simplest, most consistent and easiest to understand method would be
to drag the folder to the package list to set the path. The change
happens in the package manager to the install path, where the user is
doing the drop and no 'temporary' files are required, so nothing to
undo. If the root of a drive is the intended location then the set path
can be edited to suit, it's not difficult. KISS rules - (Keep It Simple
Stupid)!
Grahame.
Vince M Hudd
Jun 3, 2013, 6:43:21 AM6/3/13
to
Grahame Parish <maillis...@millers-way.net> wrote:
[...]
> The simplest, most consistent and easiest to understand method would be to
> drag the folder to the package list to set the path.
Which I have also suggested.
For the record.
[...]
> The simplest, most consistent and easiest to understand method would be to
> drag the folder to the package list to set the path.
For the record.
Alan
Jun 3, 2013, 8:00:06 AM6/3/13
to
On Monday, 3 June 2013 11:43:21 UTC+1, Vince M Hudd wrote:
to incorporate some of the feedback I've received. One thing I do intend to
do is to make it so that you can drag the folder to the writeable field
with the path in to set the install location.
I think you are quite correct in what it does at the moment is
drag-and-not-drop, but it seems I'm not the only person who is OK with
the current way of working. I guess it should be called drag-to-set-location
or something else.
My current thinking is I'd rather not drop something temporary to the
destination folder that will be replaced as it seems a bit like
drag-and-drop-something-else to me, but I can see how it would work.
Hopefully, by providing the drag to target and drag folder to package
window path field will be a suitable compromise for most people.
Regards,
Alan
> Grahame Parish wrote:
>
> [...]
>
> > The simplest, most consistent and easiest to understand method would be to
> > drag the folder to the package list to set the path.
>
> Which I have also suggested.
>
Vince, I'm slowly working towards a new version of the TestDrag application
>
> [...]
>
> > The simplest, most consistent and easiest to understand method would be to
> > drag the folder to the package list to set the path.
>
> Which I have also suggested.
>
to incorporate some of the feedback I've received. One thing I do intend to
do is to make it so that you can drag the folder to the writeable field
with the path in to set the install location.
I think you are quite correct in what it does at the moment is
drag-and-not-drop, but it seems I'm not the only person who is OK with
the current way of working. I guess it should be called drag-to-set-location
or something else.
My current thinking is I'd rather not drop something temporary to the
destination folder that will be replaced as it seems a bit like
drag-and-drop-something-else to me, but I can see how it would work.
Hopefully, by providing the drag to target and drag folder to package
window path field will be a suitable compromise for most people.
Regards,
Alan
Vince M Hudd
Jun 3, 2013, 8:36:35 AM6/3/13
to
Alan <alan...@hotmail.com> wrote:
> On Monday, 3 June 2013 11:43:21 UTC+1, Vince M Hudd wrote:
> > Grahame Parish wrote:
> > [...]
> > > The simplest, most consistent and easiest to understand method would
> > > be to drag the folder to the package list to set the path.
> > Which I have also suggested.
> Vince, I'm slowly working towards a new version of the TestDrag
> application to incorporate some of the feedback I've received. One thing I
> do intend to do is to make it so that you can drag the folder to the
> writeable field with the path in to set the install location.
Excellent news.
> On Monday, 3 June 2013 11:43:21 UTC+1, Vince M Hudd wrote:
> > Grahame Parish wrote:
> > [...]
> > > The simplest, most consistent and easiest to understand method would
> > > be to drag the folder to the package list to set the path.
> > Which I have also suggested.
> Vince, I'm slowly working towards a new version of the TestDrag
> application to incorporate some of the feedback I've received. One thing I
> do intend to do is to make it so that you can drag the folder to the
> writeable field with the path in to set the install location.
> I think you are quite correct in what it does at the moment is
> drag-and-not-drop, but it seems I'm not the only person who is OK with the
> current way of working. I guess it should be called drag-to-set-location
> or something else.
That the user's attention is focused over the window where they
not-drop/release, but the visual feedback doesn't take place there.
> My current thinking is I'd rather not drop something temporary to the
> destination folder that will be replaced as it seems a bit like
> drag-and-drop-something-else to me, but I can see how it would work.
However, I'm not sure that's necessarily as big an issue as you/he thinks:
what is being dragged? I'm nowhere near RISC OS at the moment, so I can't
check - but IIRC, isn't it a package icon? So you are already *dragging*
(and, ahem, not-dropping :p ) something else.
Heh.
You don't like the idea of drag-and-drop-something-else, so you're employing
drag-and-not-drop-something-else - or drag-something-else-and-not-drop-it.
:p
I've actually just had a further thought on this issue, as well - which
actually harks back to a suggestion someone else made in an entirely
different thread and combines it with the suggestion of dropping a
temporary/placeholder file.
You've already adopted a reasonable compromise, but I'm going to suggest
this anyway, just so it's on record that I've suggested it when someone else
comes along and suggests it and/or tells me I didn't suggest it:
Something that I'm sure has been suggested in a previous discussion is that
it would be nice if PackMan could respond to a double click on a package
file by offering to install whatever is contained therein. That remains a
good idea.
So, with that in mind - as well as that, IIRC, the dragged item is a
representation of a package - what if the release resulted in a
PackMan-generated pseudo package file? It would have the same filetype as a
normal package, but it would contain something to tell PackMan what package
the user was in the process of installing.
When a package file is double clicked, if it's a normal package file,
PackMan would offer to install it - as per the original suggestion above -
and if it's not a normal package file, but is one of these pseudo packages,
PackMan would read the file it put there, so it knows what package it was,
and offer to install it.
This has a number of advantages:
1) Drag and drop really does drop something: The user is seeing something
appear in the directory viewer that is the focus of their attention when
they release the mouse.
2) What you are dropping is very precisely what you dragged - a package
(which would be given the name of whatever the draggable item would be, and
this would work for applications and files.
3) PackMan doesn't need to remember what packages were selected for
installation, but the task wasn't completed: The dropped packages
effectively do that for you.
4) You gain an additional useful feature: responding to double clicks on a
separately sourced package file.
I'd say that's the ideal solution - so cue a thread in which the idea is
dismissed until someone else comes along to suggest it.
> Hopefully, by providing the drag to target and drag folder to package
> window path field will be a suitable compromise for most people.
Chris Evans
Jun 3, 2013, 8:54:11 AM6/3/13
to
In article <mpro.mns5a700n...@softrock.co.uk>, Vince M Hudd
What are you going to call the placeholder? "PlaceHolder",
"YourAppWillBeInstalledHere"!...
If you were to use the apps name then they would probably think it had been
installed.
AIUI In windows it will put the file name where you drop it in the window,
with RISC OS it is always appears in its sorted position, so may well not be
visible anyway.
What if the user changes there mind and wants to put it elsewhere or they
forget to actualy says OK Install now, which I think will happen quite often.
In Windows if it asks me where to install something and you use the browse
option it doesn't save a 'Placeholder' it updates a writable Icon
> And then I said it again.
>
> And I think I might have said it at least one more time after that, possibly
> twice. Or more.
>
> > All newbies will expect a PeeCee style confirmation button - which already
> > exists in the installer.
>
> New users, unfamiliar with RISC OS, are part of the reason I've made such a
> fuss about this. We harp on about how intuitive our drag and drop is, and
> then we completely muddy that by adding drag and not-drop just to confuse
> them.
There are always exceptions.
If a placeholder was adopted I would expect more support telephone calls:-(
So I'm putting my money where my mouth is!
<URL:mailto:vin...@softrock.co.uk> wrote:
> spampling <spam....@btinternet.com> wrote:
> > In article <53550c...@invalid.org.uk>,
> > Tim Hill <t...@invalid.org.uk> wrote:
>
> > > It may be what we are used to but Vince has a pedantic point with his
> > > drag-and-drop-doesn't-drop as nothing appears at the drop location (on
> > > the set path) until later in a multi-install situation. A placeholder
> > > file which appears at the drop location would at least give a visual
> > > indication that something has happened /at the drop point/.
>
> > Excellent idea:
> > Drag and drop as expected.
> > Visibly has dropped an item so no confusion about where it is going.
>
> Which is what I suggested *very early* in this thread.
Sorry but I see many pitfalls.
> spampling <spam....@btinternet.com> wrote:
> > In article <53550c...@invalid.org.uk>,
> > Tim Hill <t...@invalid.org.uk> wrote:
>
> > > It may be what we are used to but Vince has a pedantic point with his
> > > drag-and-drop-doesn't-drop as nothing appears at the drop location (on
> > > the set path) until later in a multi-install situation. A placeholder
> > > file which appears at the drop location would at least give a visual
> > > indication that something has happened /at the drop point/.
>
> > Excellent idea:
> > Drag and drop as expected.
> > Visibly has dropped an item so no confusion about where it is going.
>
> Which is what I suggested *very early* in this thread.
What are you going to call the placeholder? "PlaceHolder",
"YourAppWillBeInstalledHere"!...
If you were to use the apps name then they would probably think it had been
installed.
AIUI In windows it will put the file name where you drop it in the window,
with RISC OS it is always appears in its sorted position, so may well not be
visible anyway.
What if the user changes there mind and wants to put it elsewhere or they
forget to actualy says OK Install now, which I think will happen quite often.
In Windows if it asks me where to install something and you use the browse
option it doesn't save a 'Placeholder' it updates a writable Icon
> And then I said it again.
>
> And I think I might have said it at least one more time after that, possibly
> twice. Or more.
>
> > All newbies will expect a PeeCee style confirmation button - which already
> > exists in the installer.
>
> New users, unfamiliar with RISC OS, are part of the reason I've made such a
> fuss about this. We harp on about how intuitive our drag and drop is, and
> then we completely muddy that by adding drag and not-drop just to confuse
> them.
If a placeholder was adopted I would expect more support telephone calls:-(
So I'm putting my money where my mouth is!
Vince M Hudd
Jun 3, 2013, 10:21:26 AM6/3/13
to
Chris Evans <ch...@cjemicros.co.uk> wrote:
> In article <mpro.mns5a700n...@softrock.co.uk>, Vince M Hudd
> <URL:mailto:vin...@softrock.co.uk> wrote:
[Drop a placeholder where the installation would take place]
> In article <mpro.mns5a700n...@softrock.co.uk>, Vince M Hudd
> <URL:mailto:vin...@softrock.co.uk> wrote:
> > Which is what I suggested *very early* in this thread.
> Sorry but I see many pitfalls.
> What are you going to call the placeholder? "PlaceHolder",
> "YourAppWillBeInstalledHere"!...
what is dropped is given the name of whatever is to be installed at that
location.
So if you are dropping !SomeApp, what would appear in the destination would
be called !SomeApp.
> If you were to use the apps name then they would probably think it had
> been installed.
saying something should appear there, and went on to explain what that
something should *do* if clicked.
The first version of this suggestion was for a pseudo-app - a simple app
that, when double clicked, would invoke PackMan, and that in turn would
present the user with a message to say something along the lines of
"Installation of this app is not yet complete. Would you like me to
proceed?"
When Martin pointed out that wouldn't work if the object being installed is
a file (although the package format doesn't [yet] allow that anyway), I
modified the suggestion to a file: Specifically, an obey file. The contents
of the obey file would perform a similar function to the original pseudo app
suggestion - invoke PackMan to display the message etc.
And today I've improved on the idea still further, by suggesting the dropped
item be a pseudo-package file - something generated by PackMan itself.
Double clicking that would cause PackMan to do as above.
(And to the advantages I gave when I used the package file idea, I've just
realised there is also this one: Ignoring RiscPkg as being dodo-like, if the
package filetype were used in this way then any other package managers that
might be written in the future could also respond to double clicks on
package files in the same way.)
> AIUI In windows it will put the file name where you drop it in the window,
> with RISC OS it is always appears in its sorted position, so may well not
> be visible anyway. What if the user changes there mind and wants to put it
> elsewhere or they forget to actualy says OK Install now, which I think
> will happen quite often.
app would pass a message to PackMan so it could offer to proceed with the
installation. (I didn't mention options to cancel - and therefore remove the
app - or leave it until another time, but that should go without saying).
> In Windows if it asks me where to install something and you use the browse
> option it doesn't save a 'Placeholder' it updates a writable Icon
which is that this sort of thing is carried out in a window specifically
opened for the purpose (ISTR the actual terminology is "file selector" or
something like that - but it's been quite a while since I did any Windows
development work). That window is opened, and the folders [and files] are
shown therein. When you're done - whether it's a save, or you've chosen a
location, etc, the action takes place in that window, *which immediately
closes*.
You're comparing that with RISC OS, in which you are dragging to an already
open filer window - something that isn't opened or controlled by the app
itself, and which is therefore not *closed* by the app when you've finished.
> > New users, unfamiliar with RISC OS, are part of the reason I've made
> > such a fuss about this. We harp on about how intuitive our drag and drop
> > is, and then we completely muddy that by adding drag and not-drop just
> > to confuse them.
> There are always exceptions.
> If a placeholder was adopted I would expect more support telephone
> calls:-( So I'm putting my money where my mouth is!
clearly be a big pitfall - but my suggestion has always been for something
more than that.
We are talking about files on computers, after all. We can actually program
them to, you know, do stuff with those files.
druck
Jun 3, 2013, 2:36:54 PM6/3/13
to
On 03/06/2013 09:37, Vince M Hudd wrote:
> The only thing I *don't* want is drag and not-drop - at least not as the
> only option, so I can do something logical and be oblivious to what the
> crazy folk are doing.
Please can we stop using the meaningless phrase of "drag and not-drop",
> only option, so I can do something logical and be oblivious to what the
> crazy folk are doing.
there is no such paradigm in RISC OS or anything else.
---druck
Vince M Hudd
Jun 3, 2013, 4:05:31 PM6/3/13
to
is and that, for those not paying attention at the back, is why I keep using
the bloody term.
If you don't like that, don't read my posts.
druck
Jun 3, 2013, 4:13:05 PM6/3/13
to
On 03/06/2013 21:05, Vince M Hudd wrote:
> druck <ne...@druck.org.uk> wrote:
>> On 03/06/2013 09:37, Vince M Hudd wrote:
>
>>> The only thing I *don't* want is drag and not-drop - at least not as the
>>> only option, so I can do something logical and be oblivious to what the
>>> crazy folk are doing.
>
>> Please can we stop using the meaningless phrase of "drag and not-drop",
>> there is no such paradigm in RISC OS or anything else.
>
> I agree that there *shouldn't* be a drag and not-drop paradigm - but there
> is and that, for those not paying attention at the back, is why I keep using
> the bloody term.
But the term is wrong. There is still a process of dragging something
> druck <ne...@druck.org.uk> wrote:
>> On 03/06/2013 09:37, Vince M Hudd wrote:
>
>>> The only thing I *don't* want is drag and not-drop - at least not as the
>>> only option, so I can do something logical and be oblivious to what the
>>> crazy folk are doing.
>
>> Please can we stop using the meaningless phrase of "drag and not-drop",
>> there is no such paradigm in RISC OS or anything else.
>
> I agree that there *shouldn't* be a drag and not-drop paradigm - but there
> is and that, for those not paying attention at the back, is why I keep using
> the bloody term.
and dropping (releasing) it over an area of the screen. This is
regardless of whether any entity is created at that location,
immediately or at a later time.
> If you don't like that, don't read my posts.
---druck
Vince M Hudd
Jun 3, 2013, 4:24:02 PM6/3/13
to
druck <ne...@druck.org.uk> wrote:
> On 03/06/2013 21:05, Vince M Hudd wrote:
> > > Please can we stop using the meaningless phrase of "drag and
> > > not-drop", there is no such paradigm in RISC OS or anything else.
> > I agree that there *shouldn't* be a drag and not-drop paradigm - but
> > there is and that, for those not paying attention at the back, is why I
> > keep using the bloody term.
> But the term is wrong. There is still a process of dragging something and
> dropping (releasing) it over an area of the screen. This is regardless of
> whether any entity is created at that location, immediately or at a later
> time.
Quite. It's more like "drag and drop through a virtual wormhole to cause
> On 03/06/2013 21:05, Vince M Hudd wrote:
> > > Please can we stop using the meaningless phrase of "drag and
> > > not-drop", there is no such paradigm in RISC OS or anything else.
> > I agree that there *shouldn't* be a drag and not-drop paradigm - but
> > there is and that, for those not paying attention at the back, is why I
> > keep using the bloody term.
> But the term is wrong. There is still a process of dragging something and
> dropping (releasing) it over an area of the screen. This is regardless of
> whether any entity is created at that location, immediately or at a later
> time.
something somewhere else to be updated" - but drag and not-drop is quicker
to type, and is a suitably disparaging term for expressing my dislike of it.
> > If you don't like that, don't read my posts.
> No need to drag and not drop your toys out of the pram!
Alan
Dec 17, 2013, 7:53:24 AM12/17/13
to
> Alan Buckley wrote:
>
> [Snip]
>
> Please take a look at this and send me any feedback on it - good or
> bad. If you don't like it, alternative ideas would be greatly
> appreciated.
>
Thanks to everyone for the useful feedback in this thread. I've
now released PackMan 0.8 which incorporates a lot of the ideas
from here and is much better for it than my original design.
Unfortunately, the most interesting section for the components
is sparsely populated at the moment as packages need to be
updated before it is used. As I write this only PackIt has
been updated, but the rest of the packages I maintain should
appear soon.
I'm unlikely to make any major changes to the interface now,
but as always feedback and suggestions are welcome.
Thanks again,
Alan
>
> [Snip]
>
> Please take a look at this and send me any feedback on it - good or
> bad. If you don't like it, alternative ideas would be greatly
> appreciated.
>
Thanks to everyone for the useful feedback in this thread. I've
now released PackMan 0.8 which incorporates a lot of the ideas
from here and is much better for it than my original design.
Unfortunately, the most interesting section for the components
is sparsely populated at the moment as packages need to be
updated before it is used. As I write this only PackIt has
been updated, but the rest of the packages I maintain should
appear soon.
I'm unlikely to make any major changes to the interface now,
but as always feedback and suggestions are welcome.
Thanks again,
Alan
Theo Markettos
Dec 17, 2013, 1:49:28 PM12/17/13
to
Alan <alan...@hotmail.com> wrote:
> Unfortunately, the most interesting section for the components
> is sparsely populated at the moment as packages need to be
> updated before it is used. As I write this only PackIt has
> been updated, but the rest of the packages I maintain should
> appear soon.
What needs to be updated, out of interest?
> Unfortunately, the most interesting section for the components
> is sparsely populated at the moment as packages need to be
> updated before it is used. As I write this only PackIt has
> been updated, but the rest of the packages I maintain should
> appear soon.
Theo
Alan
Dec 17, 2013, 3:13:54 PM12/17/13
to
On Tuesday, December 17, 2013 6:49:28 PM UTC, Theo Markettos wrote:
You just need to add a new field to the control record called Components with the logical path to the component and some flags in brackets and update the standards version. I added a link to the announcement with details.
You can also discard the Sprites and SysVars metadata as the new format allows you to specify the component is added to look at.
regards,
Alan
You can also discard the Sprites and SysVars metadata as the new format allows you to specify the component is added to look at.
regards,
Alan
John Rickman Iyonix
Dec 21, 2013, 1:59:31 PM12/21/13
to
Alan wrote
> Thanks to everyone for the useful feedback in this thread. I've
> now released PackMan 0.8 which incorporates a lot of the ideas
> from here and is much better for it than my original design.
Thanks to Martin Bazely's detailed description of installing Packman
on another thread I didn't want to break into. I was encouraged to
give it a go.
The installation proceeded much as Martin described it, including the
conflict with SharedUlib. (Conflict is not the best word for this
situation - Martin has covered this with suggestion to use RMEnsure)
Looking at the PackMan list I noticed a comforting green tick against
Packman. Less comforting was the segmentation fault and backtrace dump
that occurred when I asked for info on Packman from the menu.
After a restart of PackMan I cannot reproduce the seg fault. (I did
not take a note of the details, expecting to find them in the Reporter
list - they were not there)
Next I installed Packit. Got Conflict with toolbox.Tabs and chose
update. Good move, probably, the replaced Tabs was dated 2004, the new
one 2013.
Then, via the apps window and menu > move, I moved PackMan and Packit
to where I would like them to reside.
PackMan has improved a lot since I last used it.
A couple of minor criticisms:
1. The information window for an installed package does not say where
the package is. Could you not show this information? It must be in the
set of "known knowns"
2. The PackMan install created a nested directory Apps.Admin in my
root drive. Occasionally a program may dump a file into root for want
of somewhere to put it in an emergency. For several reasons I don't
have an Apps directory. (I keep my apps in a directory called APPZ)
and I am not happy that PackMan should create it or anything else in
root. Among other things it messes up the filer displays which are
preset to a fixed size and position in MoreDesk.
Would it not be possible to have a config option to specify a default
location for PackMan to put new installs in?
And the third item of the "couple" is a minor irritation with the
name. This letter contains the name PackMan 10 up to here. Why the
camel case? IMHO Packman is easier to write is much nicer.
John
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
> Thanks to everyone for the useful feedback in this thread. I've
> now released PackMan 0.8 which incorporates a lot of the ideas
> from here and is much better for it than my original design.
on another thread I didn't want to break into. I was encouraged to
give it a go.
The installation proceeded much as Martin described it, including the
conflict with SharedUlib. (Conflict is not the best word for this
situation - Martin has covered this with suggestion to use RMEnsure)
Looking at the PackMan list I noticed a comforting green tick against
Packman. Less comforting was the segmentation fault and backtrace dump
that occurred when I asked for info on Packman from the menu.
After a restart of PackMan I cannot reproduce the seg fault. (I did
not take a note of the details, expecting to find them in the Reporter
list - they were not there)
Next I installed Packit. Got Conflict with toolbox.Tabs and chose
update. Good move, probably, the replaced Tabs was dated 2004, the new
one 2013.
Then, via the apps window and menu > move, I moved PackMan and Packit
to where I would like them to reside.
PackMan has improved a lot since I last used it.
A couple of minor criticisms:
1. The information window for an installed package does not say where
the package is. Could you not show this information? It must be in the
set of "known knowns"
2. The PackMan install created a nested directory Apps.Admin in my
root drive. Occasionally a program may dump a file into root for want
of somewhere to put it in an emergency. For several reasons I don't
have an Apps directory. (I keep my apps in a directory called APPZ)
and I am not happy that PackMan should create it or anything else in
root. Among other things it messes up the filer displays which are
preset to a fixed size and position in MoreDesk.
Would it not be possible to have a config option to specify a default
location for PackMan to put new installs in?
And the third item of the "couple" is a minor irritation with the
name. This letter contains the name PackMan 10 up to here. Why the
camel case? IMHO Packman is easier to write is much nicer.
John
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Martin Bazley
Dec 22, 2013, 4:16:41 AM12/22/13
to
The following bytes were arranged on 21 Dec 2013 by John Rickman Iyonix :
> Thanks to Martin Bazely's
Who?
> Looking at the PackMan list I noticed a comforting green tick against
> Packman. Less comforting was the segmentation fault and backtrace dump
> that occurred when I asked for info on Packman from the menu.
That's one I didn't see. I wonder if this stuff only occurs after
you've installed something? It would explain the non-reproducibility.
> 1. The information window for an installed package does not say where
> the package is. Could you not show this information? It must be in the
> set of "known knowns"
Unfortunately, one package does not necessarily map to one application -
it's perfectly valid for the same package to contain two applications,
both of which are installed in different places. There is no concept of
the "package install location", only of individual components within it.
I suggest - for a number of reasons, including your point number 2 in
that PackMan has an annoying habit of creating pointless directories -
that rather than persisting with the universally unpopular fixed install
locations, PackMan instead bodges together a fake list of components for
any packages which do not support them. This is how the Apps window
works in any case - scanning through the archive and adding any
applications found to a list - which could well become that package's
list of components.
The components list (or window, or whatever we're going with) could then
be added to the information window, along with the install location of
each.
The one drawback to this approach is that it doesn't support obsolete
packages which distribute non-application payloads. Fortunately, I do
not believe any such packages have ever existed. Apart from anything
else, since they would also not show up in the Apps window you wouldn't
be able to move them!
--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
\_> <_/ ======================= Martin Bazley ==========================
> Thanks to Martin Bazely's
> Looking at the PackMan list I noticed a comforting green tick against
> Packman. Less comforting was the segmentation fault and backtrace dump
> that occurred when I asked for info on Packman from the menu.
you've installed something? It would explain the non-reproducibility.
> 1. The information window for an installed package does not say where
> the package is. Could you not show this information? It must be in the
> set of "known knowns"
it's perfectly valid for the same package to contain two applications,
both of which are installed in different places. There is no concept of
the "package install location", only of individual components within it.
I suggest - for a number of reasons, including your point number 2 in
that PackMan has an annoying habit of creating pointless directories -
that rather than persisting with the universally unpopular fixed install
locations, PackMan instead bodges together a fake list of components for
any packages which do not support them. This is how the Apps window
works in any case - scanning through the archive and adding any
applications found to a list - which could well become that package's
list of components.
The components list (or window, or whatever we're going with) could then
be added to the information window, along with the install location of
each.
The one drawback to this approach is that it doesn't support obsolete
packages which distribute non-application payloads. Fortunately, I do
not believe any such packages have ever existed. Apart from anything
else, since they would also not show up in the Apps window you wouldn't
be able to move them!
--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
\_> <_/ ======================= Martin Bazley ==========================
John Rickman Iyonix
Dec 22, 2013, 1:53:40 PM12/22/13
to
> John Rickman Iyonix wrote:
>> Thanks to Martin Bazely's
> Who?
sorry:(
>> Thanks to Martin Bazely's
> Who?
>> 1. The information window for an installed package does not say where
>> the package is. Could you not show this information? It must be in the
>> set of "known knowns"
> Unfortunately, one package does not necessarily map to one application -
...
> I suggest - for a number of reasons, including your point number 2 in
> that PackMan has an annoying habit of creating pointless directories -
It was not until I tried to make a Package using Packit that I really
> that PackMan has an annoying habit of creating pointless directories -
became aware that PackMan is a "Pusher" app.
The mental model I had of software installation involved me "Pulling"
an app and putting it somewhere.
One of the steps of Packit is the selection from a list of where you
would like your software to be installed. I found this difficult. None
of the 32 locations offered seemed right so I invented another.
The difficulty was in not wanting to presume where to install my app
on another person's machine. This reluctance to specify a location
does not extend to components. It is perfectly reasonable to place
modules etc in fixed places.
> ...rather than persisting with the universally unpopular fixed install
> locations, PackMan instead bodges together a fake list of components for
> any packages which do not support them. This is how the Apps window
> works in any case - scanning through the archive and adding any
> applications found to a list - which could well become that package's
> list of components.
I don't really understand this suggestion
> any packages which do not support them. This is how the Apps window
> works in any case - scanning through the archive and adding any
> applications found to a list - which could well become that package's
> list of components.
> The components list (or window, or whatever we're going with) could then
> be added to the information window, along with the install location of
> each.
at any terminus
Martin Bazley
Dec 23, 2013, 8:26:59 AM12/23/13
to
The following bytes were arranged on 22 Dec 2013 by John Rickman Iyonix :
> It was not until I tried to make a Package using Packit that I really
> became aware that PackMan is a "Pusher" app.
> The mental model I had of software installation involved me "Pulling"
> an app and putting it somewhere.
Well, yes. You and every other RISC OS user. This is why PackMan is
widely disliked.
The recent set of changes described in this thread go some way towards
turning that list of fixed installation locations into something more
akin to a 'pulling' model, where you specify a list of things which can
be dragged out of the zip to a location of the user's choice. It
doesn't go nearly far enough, though, and if the natural conclusion you
came to when trying to build a package was that this feature didn't even
exist then that shows how bodged-on to a badly designed format it is.
I'd like to see the list of installation locations abolished completely,
aside from a small number of hardcoded !Boot components, and to hell
with compatibility with earlier versions of PackMan and RiscPkg because
nobody uses them anyway, precisely because they behave like this.
> > ...rather than persisting with the universally unpopular fixed install
> > locations, PackMan instead bodges together a fake list of components for
> > any packages which do not support them. This is how the Apps window
> > works in any case - scanning through the archive and adding any
> > applications found to a list - which could well become that package's
> > list of components.
>
> I don't really understand this suggestion
It wasn't aimed at you anyway, but it has to do with the recent changes
made to the PackMan standard aimed at combating exactly the problem you
encountered.
--
__<^>__
/ _ _ \ You always find something in the last place you look.
> It was not until I tried to make a Package using Packit that I really
> became aware that PackMan is a "Pusher" app.
> The mental model I had of software installation involved me "Pulling"
> an app and putting it somewhere.
widely disliked.
The recent set of changes described in this thread go some way towards
turning that list of fixed installation locations into something more
akin to a 'pulling' model, where you specify a list of things which can
be dragged out of the zip to a location of the user's choice. It
doesn't go nearly far enough, though, and if the natural conclusion you
came to when trying to build a package was that this feature didn't even
exist then that shows how bodged-on to a badly designed format it is.
I'd like to see the list of installation locations abolished completely,
aside from a small number of hardcoded !Boot components, and to hell
with compatibility with earlier versions of PackMan and RiscPkg because
nobody uses them anyway, precisely because they behave like this.
> > ...rather than persisting with the universally unpopular fixed install
> > locations, PackMan instead bodges together a fake list of components for
> > any packages which do not support them. This is how the Apps window
> > works in any case - scanning through the archive and adding any
> > applications found to a list - which could well become that package's
> > list of components.
>
> I don't really understand this suggestion
made to the PackMan standard aimed at combating exactly the problem you
encountered.
--
__<^>__
/ _ _ \ You always find something in the last place you look.
( ( |_| ) )
Alan
Dec 23, 2013, 8:52:41 AM12/23/13
to
On Saturday, December 21, 2013 6:59:31 PM UTC, John Rickman Iyonix wrote:
> Alan wrote
>
> > Thanks to everyone for the useful feedback in this thread. I've
> > now released PackMan 0.8 which incorporates a lot of the ideas
> > from here and is much better for it than my original design.
>
> Thanks to Martin Bazely's detailed description of installing Packman
> on another thread I didn't want to break into. I was encouraged to
> give it a go.
Thanks for trying it.
> Alan wrote
>
> > Thanks to everyone for the useful feedback in this thread. I've
> > now released PackMan 0.8 which incorporates a lot of the ideas
> > from here and is much better for it than my original design.
>
> Thanks to Martin Bazely's detailed description of installing Packman
> on another thread I didn't want to break into. I was encouraged to
> give it a go.
>
> The installation proceeded much as Martin described it, including the
> conflict with SharedUlib. (Conflict is not the best word for this
> situation - Martin has covered this with suggestion to use RMEnsure)
>
Yes, and I agree it's something I need to address.
> The installation proceeded much as Martin described it, including the
> conflict with SharedUlib. (Conflict is not the best word for this
> situation - Martin has covered this with suggestion to use RMEnsure)
>
>
>
> Looking at the PackMan list I noticed a comforting green tick against
> Packman. Less comforting was the segmentation fault and backtrace dump
> that occurred when I asked for info on Packman from the menu.
>
> After a restart of PackMan I cannot reproduce the seg fault. (I did
> not take a note of the details, expecting to find them in the Reporter
> list - they were not there)
Sorry you had a crash. I wouldn't have released it if I had been
>
> Looking at the PackMan list I noticed a comforting green tick against
> Packman. Less comforting was the segmentation fault and backtrace dump
> that occurred when I asked for info on Packman from the menu.
>
> After a restart of PackMan I cannot reproduce the seg fault. (I did
> not take a note of the details, expecting to find them in the Reporter
> list - they were not there)
experiencing these problem. I'll look at the code again, but it's
hard to find and fix things without more details.
>
>
> Next I installed Packit. Got Conflict with toolbox.Tabs and chose
> update. Good move, probably, the replaced Tabs was dated 2004, the new
> one 2013.
you if it is going to replace a non-packaged item. With the
future module improvement it may not need to do this in future
at least with modules like Tabs.
>
> Then, via the apps window and menu > move, I moved PackMan and Packit
> to where I would like them to reside.
>
> PackMan has improved a lot since I last used it.
>
>
> A couple of minor criticisms:
>
> 1. The information window for an installed package does not say where
> the package is. Could you not show this information? It must be in the
> set of "known knowns"
>
This is a good idea. With the new component system it should be able
> A couple of minor criticisms:
>
> 1. The information window for an installed package does not say where
> the package is. Could you not show this information? It must be in the
> set of "known knowns"
>
to show the components for the package and where they have been/will
be installed.
>
>
> 2. The PackMan install created a nested directory Apps.Admin in my
> root drive. Occasionally a program may dump a file into root for want
> of somewhere to put it in an emergency. For several reasons I don't
> have an Apps directory. (I keep my apps in a directory called APPZ)
> and I am not happy that PackMan should create it or anything else in
> root. Among other things it messes up the filer displays which are
> preset to a fixed size and position in MoreDesk.
>
> Would it not be possible to have a config option to specify a default
> location for PackMan to put new installs in?
>
Off the iconbar menu under the Advanced submenu is a Paths option.
>
> 2. The PackMan install created a nested directory Apps.Admin in my
> root drive. Occasionally a program may dump a file into root for want
> of somewhere to put it in an emergency. For several reasons I don't
> have an Apps directory. (I keep my apps in a directory called APPZ)
> and I am not happy that PackMan should create it or anything else in
> root. Among other things it messes up the filer displays which are
> preset to a fixed size and position in MoreDesk.
>
> Would it not be possible to have a config option to specify a default
> location for PackMan to put new installs in?
>
This allows you to set default installation locations.
>
> And the third item of the "couple" is a minor irritation with the
> name. This letter contains the name PackMan 10 up to here. Why the
> camel case? IMHO Packman is easier to write is much nicer.
>
It was just my thoughts when I came up with the name, as it was
> And the third item of the "couple" is a minor irritation with the
> name. This letter contains the name PackMan 10 up to here. Why the
> camel case? IMHO Packman is easier to write is much nicer.
>
short for two words Package Manager. Sorry it irritates you.
Regards,
Alan
Alan
Dec 23, 2013, 10:08:51 AM12/23/13
to
On Monday, December 23, 2013 1:26:59 PM UTC, Martin Bazley wrote:
> The following bytes were arranged on 22 Dec 2013 by John Rickman Iyonix :
>
> > It was not until I tried to make a Package using Packit that I really
> > became aware that PackMan is a "Pusher" app.
> > The mental model I had of software installation involved me "Pulling"
> > an app and putting it somewhere.
>
I'm not sure of the terminology here. PackMan just pulls the
> The following bytes were arranged on 22 Dec 2013 by John Rickman Iyonix :
>
> > It was not until I tried to make a Package using Packit that I really
> > became aware that PackMan is a "Pusher" app.
> > The mental model I had of software installation involved me "Pulling"
> > an app and putting it somewhere.
>
applications from the servers and puts it on your disk for you.
The biggest complaint was that the UI did not make it easy for
you to put it where you wanted as you installed it. You could
always configure where it went, but it wasn't encouraged.
The install location was originally the recommended location
and it was actively discouraged to put it elsewhere. My work
has changed this so the install location is a suggested/or
default location so you can do a quick install.
> Well, yes. You and every other RISC OS user. This is why PackMan is
> widely disliked.
of encouragement than I have seen complaints on the groups. That's
not to say anyone thinks it's perfect and can't be improved, but
most people offer constructive suggestions and criticism to help
me make it better.
>
> The recent set of changes described in this thread go some way towards
> turning that list of fixed installation locations into something more
> akin to a 'pulling' model, where you specify a list of things which can
> be dragged out of the zip to a location of the user's choice. It
> doesn't go nearly far enough, though, and if the natural conclusion you
> came to when trying to build a package was that this feature didn't even
> exist then that shows how bodged-on to a badly designed format it is.
>
new flexibility the straight jackets on install location have been
removed. I've tried to change the PackIt documentation to make this
clearer.
There is nothing fundamentally bodged-up or bad about the design. It's
open and flexible. But I doubt we'll ever agree on this point.
>
> I'd like to see the list of installation locations abolished completely,
> aside from a small number of hardcoded !Boot components, and to hell
> with compatibility with earlier versions of PackMan and RiscPkg because
> nobody uses them anyway, precisely because they behave like this.
>
> > > ...rather than persisting with the universally unpopular fixed install
> > > locations, PackMan instead bodges together a fake list of components for
> > > any packages which do not support them. This is how the Apps window
> > > works in any case - scanning through the archive and adding any
> > > applications found to a list - which could well become that package's
> > > list of components.
>
> > I don't really understand this suggestion
> It wasn't aimed at you anyway, but it has to do with the recent changes
> made to the PackMan standard aimed at combating exactly the problem you
> encountered.
>
it doesn't have a list of all the files for a package until after
it is downloaded.
Regards,
Alan
John
Dec 23, 2013, 11:31:05 AM12/23/13
to
In article <c6e5a6bd5...@rickman.argonet.co.uk>, John
observed) that camel case is used, eg,
WordWise
TurboDriver
InterWord/Sheet/Base
WorWorks
ArtWorks
TechWriter
StrongED (bactrian, not dromedary)
StrongHelp
StrongMen
TableMate
TempDir
EasyFont
DrawWorks
DrivePop (I don't expect you to know that one - VRPC)
NetSurf
ShowScrap
ConvText
EasiRes
SysLogs
UnixHome
DPingScan
NewHall
MathPhys...
Give up yet? ;-)
It's also another differentiator between RISC OS and
Windows.
John
--
John
new...@blueyonder.co.uk
j dot mccartney atte blueyonder dot co dot uk
Rickman Iyonix <ric...@argonet.co.uk> wrote:
> Why the camel case? IMHO Packman is easier to write is
> much nicer.
It seems to be a RISC OS tradition (though not universally
> Why the camel case? IMHO Packman is easier to write is
> much nicer.
observed) that camel case is used, eg,
WordWise
TurboDriver
InterWord/Sheet/Base
WorWorks
ArtWorks
TechWriter
StrongED (bactrian, not dromedary)
StrongHelp
StrongMen
TableMate
TempDir
EasyFont
DrawWorks
DrivePop (I don't expect you to know that one - VRPC)
NetSurf
ShowScrap
ConvText
EasiRes
SysLogs
UnixHome
DPingScan
NewHall
MathPhys...
Give up yet? ;-)
It's also another differentiator between RISC OS and
Windows.
John
--
John
new...@blueyonder.co.uk
j dot mccartney atte blueyonder dot co dot uk
Ron Briscoe
Dec 23, 2013, 1:24:13 PM12/23/13
to
In article <c01f90be...@blueyonder.co.uk>,
criticism instead of acerbic comments like the above.
What few software developers we have left, including yourself, should be
encouraged and not discouraged in their efforts.
[Snip rest of indigestion driven diatribe.]
Regards Ron.
Martin Bazley <martin...@blueyonder.co.uk> wrote:
> > It was not until I tried to make a Package using Packit that I really
> > became aware that PackMan is a "Pusher" app.
> > The mental model I had of software installation involved me "Pulling"
> > an app and putting it somewhere.
> Well, yes. You and every other RISC OS user. This is why PackMan is
> widely disliked.
Well I like Packman and could you please keep your posts to constructive
> > It was not until I tried to make a Package using Packit that I really
> > became aware that PackMan is a "Pusher" app.
> > The mental model I had of software installation involved me "Pulling"
> > an app and putting it somewhere.
> Well, yes. You and every other RISC OS user. This is why PackMan is
> widely disliked.
criticism instead of acerbic comments like the above.
What few software developers we have left, including yourself, should be
encouraged and not discouraged in their efforts.
[Snip rest of indigestion driven diatribe.]
Regards Ron.
TynHau News
Dec 23, 2013, 1:51:54 PM12/23/13
to
It is loading more messages.
0 new messages