Drag and not-drop added, not-drop not dropped, but drag and real-drop added. Sort of.
In May, Alan Buckley released an update to PackMan, his alternative package manager to RiscPkg for downloading and installing RISC OS applications and other resources. Since then, he has also released a test application which shows a proof of concept of how drag and drop installation might work in future versions of PackMan, asking for feedback on the idea.
PackMan 0.7.1 is a beta version, and offers a number of new features over previous versions:
- A “What’s new” filter, which shows the user all the ‘new’ packages – those which have appeared since the repository was last checked.
- The ability to enable or disable individual package lists, which is handy if one of the sources becomes unavailable.
- The ability to add or remove paths, which – according to Alan’s announcement – will allow you to “set the default directories for whole categories of packages.”
- For a new installation of PackMan (as opposed to an upgrade) the default sources lists point to the repositories found on the RISC OS Open Ltd website.
In addition to these main bullet points, Alan says there have been other minor bug fixes and improvements, with the full history being in the documentation found within the app.
Interestingly, the announcement says that “if you already have a previous version of !PackMan or !RiscPkg installed you can install it or upgrade it from either of these programs.” My attempt to do precisely that, though, was met with complete failure. The version I had installed on my Raspberry Pi was, according to its ‘Info’ window, 0.7 beta, dated 21st September, 2012. More specifically, this was version 0.7-4 according to PackMan’s list of packages – and the version available was also version 0.7-4 – which meant I couldn’t upgrade to version 0.7.1; it wasn’t there.
In order to install the new version of PackMan I had to do so the old fashioned way, by downloading the package file manually from the link in Alan’s announcement, unzipping it, and dragging the application to its installed location – the very method package management is supposed to replace!
Given my dislike of the enforced installation location of applications, when sourced via RiscPkg or PackMan – a dislike that I have been very vocal about (and which Alan is taking steps to address in PackMan) – one possible explanation for this ironic problem is that, perhaps, I had moved PackMan from where it was originally installed, without telling PackMan that I had done so. However, a quick look at the Paths window reveals that this is not the case: Where PackMan is installed on my system is indeed where the package manager thinks it is installed.
A quick investigation revealed the real explanation to be that version 0.7.1 was available via the package manager, if the repository in use was the one found on the RISC OS Packaging Project website. It’s easy to add this repository to PackMan – but note the following from PackMan’s own help files:
In late 2012, RISC OS Open created a set of packaging lists. […] It is recommend that these lists are now used.
And, further down on the same page:
The older lists add more packages, but they may not have been tested on the modern (post Iyonix) hardware so should be treated with caution.
So, if you are using RISC OS on a modern system, such as a Raspberry Pi, PandaBoard or BeagleBoard, it is not recommended that you use the RISC OS Packaging Project repository. However, if you want to install the latest version of PackMan – a RISC OS package manager – using PackMan – a RISC OS package manager – then in order to do so you should add that repository. The one that is not recommended and should be treated with caution.
Is it just me, or is there a slight flaw in that?
Alan’s related announcements were of a proof of concept application, to illustrate and promote discussion of how a drag and drop package installer might work.
The first of these appeared around the same time as version 0.7.1 of PackMan, and prompted a lengthy discussion on the merits of the approach that had been implemented – which I labelled as drag and not-drop, on the basis that users would drag the application to be installed to a suitable location on their system and release it, whereby the drop part of drag and drop wouldn’t happen. In a normal drag and drop, such as when a document is saved, the file appears in the destination folder, which is where the user’s attention is focused at that moment. In the proof of concept application, when the release happened the path icon was updated in the window from which the application was dragged.
On the comparatively small screens we were used to in the 1980s and for most of the 1990s, such a thing may probably have been acceptable, because even though the visual feedback didn’t happen where the user’s attention is focused, it would likely be close enough to it that they would notice that something had happened. These days, however, screen sizes can be a lot bigger, and resolutions can be a lot higher – and as a result the source window and destination folder might be far enough apart that the updated icon can go unnoticed, meaning there is no visual feedback for the users.
In the ongoing discussion, it emerged that this drag and not-drop approach – which I consider very strange and counter-intuitive, and wholly out of place on RISC OS – is not new. Alan’s test application was not the first to employ it, and a number other examples were cited, though they often provided alternative approaches, such as dragging the destination folder onto the window, whereby the visual feedback occurs as expected; the user is focused on window under which the dragged item is released.
Alan released a second version of his test application in June. This still has drag and not-drop as a feature, but with slightly improved visual feedback, by changing the colour of the installation path shown in the window – the idea being that after users perform the not-drop and shift their focus back to that window, the fact that the text has changed colour will register with them, so they’ll recognise that something has happened. (It might also be that even when their attention is focused on the part of the screen where the not-drop takes place, the change of colour will register in the corner of their eye.)
This second version also adopts the alternative approach of dragging the destination folder onto the installation window to update the path – and doing things this way around ensures that the visual feedback is more direct.
Download the application and see what you think. Feedback can be provided by email, at the address found in the app’s !Help file, or discussed more widely on the comp.sys.acorn.apps newsgroup.
