Stronghelp - can I change location set by Packman?

[Andrew Wickham]

The ROOL Pi image comes with Stronghelp (among other things) already
installed; it is in $.Apps and therefore appears in Resources:$.Apps.
I rarely use it, so reckoned that if it were in (say) Boot.Resources,
its location would be known to the system. But after moving it, &3d6
files won't launch directly, because the system is still looking for
SDFS:0.$.Apps.!StrongHelp.

However, somewhere in Packman the variable <Stronghelp$Dir> is being
set, overriding that set by StrongHelp's own !Boot file. This seems
unduly presumptious of Packman, since things in Apps get filer-booted
anyway - is there a way to allow StrongHelp to set its own variables?
(short of expunging Packman itself)

TIA,
Andrew

[Steve Fryatt]

On 3 Apr, Andrew Wickham wrote in message
<8a33d24f-df9e-4a84...@y14g2000vbk.googlegroups.com>:

> The ROOL Pi image comes with Stronghelp (among other things) already
> installed; it is in $.Apps and therefore appears in Resources:$.Apps. I
> rarely use it, so reckoned that if it were in (say) Boot.Resources, its
> location would be known to the system. But after moving it, &3d6 files
> won't launch directly, because the system is still looking for
> SDFS:0.$.Apps.!StrongHelp.
>
> However, somewhere in Packman the variable <Stronghelp$Dir> is being set,
> overriding that set by StrongHelp's own !Boot file. This seems unduly
> presumptious of Packman,

Not really, as anything PackMan has installed needs to stay where PackMan
installs it so that it knows where it is -- IYSWIM.

The answer to to your question is yes, you can move it -- but you must do it
from PackMan itself. Load PackMan and open the list of packages (click
Select on its iconbar icon). Select the StrongHelp package, click Menu over
it and choose 'Package->Apps...'. Click Menu again over the !StrongHelp
icon in the Apps window that opens, then select 'Apps->Move->' and drag the
resulting icon to where you want the app to live.

Doing it that way means that PackMan continues to know where StrongHelp is
stored, so that it can continue to apply updates as they become available.

[Coincidentally, I've just finished showing how to do exactly this at the
WROCC meeting this evening...]

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

[Dave Symes]

In article <mpro.mkpaf902...@stevefryatt.org.uk>,
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
[Snippy]

> Not really, as anything PackMan has installed needs to stay where PackMan
> installs it so that it knows where it is -- IYSWIM.

> The answer to to your question is yes, you can move it -- but you must
> do it from PackMan itself. Load PackMan and open the list of packages
> (click Select on its iconbar icon). Select the StrongHelp package, click
> Menu over it and choose 'Package->Apps...'. Click Menu again over the
> !StrongHelp icon in the Apps window that opens, then select
> 'Apps->Move->' and drag the resulting icon to where you want the app to
> live.

> Doing it that way means that PackMan continues to know where StrongHelp
> is stored, so that it can continue to apply updates as they become
> available.

> [Coincidentally, I've just finished showing how to do exactly this at the
> WROCC meeting this evening...]

Steve, excellent thanks, useful note, as the main reason I gave up using
it was, "it" putting things somewhere I didn't want...

It remains a strange creature, very difficult to understand and get to do
anything useful. (That's any version I've had, including below).

I assume it must work for somebody...

Dave

Version 0.7 Beta (21 Sept 2012)

It did work sort of once, but not for a long time now...
For example it won't (Ever) update the Lists, erroring out with a 404.

I never ever managed to get it, past or present to maintain Netsurf or
dependencies.

It still *appears* to work on DirSync and the Strong apps.

It won't download and install the latest version of itself (Packman).
(Never did).

I guess, who knows, I don't, the address/urls somewhere in for the package
sources now uses, don't connect to the ones already in it. (There are two).

And despite much searching can't find any info about list of sources Urls
except Ri Pi of which I have no interest.

<Shrugs shoulders and moved on>
D.

--

Dave Triffid

[Chris Johnson]

In article <5336fd2...@triffid.co.uk>,

Dave Symes <da...@triffid.co.uk> wrote:
> And despite much searching can't find any info about list of
> sources Urls except Ri Pi of which I have no interest.

These lists contain a lot of stuff that is not RPi specific - in fact
there are only about four packages on the lists that are RPi only,
i.e. ROM updates etc. For example, I am in the process of packaging
all my stuff to be hosted by ROOL on these lists, including things
like Snapper and SyncDiscs, none of which are RPi specific. It is
shortsighted to dismiss all these packages out of hand. I think the
ultimate intention is for these package lists to become the first
port of call for RISC OS software.

--
Chris Johnson

[Dave Symes]

In article <5337120d97chr...@spamcop.net>,

It might help if the list heading didn't just display Ri Pi stuff, there
are five links and they only mention the ...... Ri Pi.

That's why I dismissed/went no further.

When I get time I'll look inside and see if there actually is anything
other than...

Then what do I do with it?

Thanks for the input
Dave

--

Dave Triffid

[Martin Bazley]

The following bytes were arranged on 4 Apr 2013 by Chris Johnson :

> In article <5336fd2...@triffid.co.uk>,
> Dave Symes <da...@triffid.co.uk> wrote:

> > Ri Pi

No, seriously, what is a "Ri Pi"? I can't imagine what that's supposed
to stand for. The "Rispberry Pi"? Why do people keep calling it this?

> It is shortsighted to dismiss all these packages out of hand. I think
> the ultimate intention is for these package lists to become the first
> port of call for RISC OS software.

They'll have to knock some sense into the packaging system first. At
present, the hassle of using, never mind setting up, PackMan vastly
outweighs any theoretical benefits it may provide.

I will repeat this once again: the architecture underlying the present
system of RISC OS packages is fundamentally wrong and needs a total
rethink. PackMan's manner of operation is completely at odds with the
operating system for which it is written. Whoever thought it was a good
idea to abandon the standard, established system of installing by drag
and drop?

And I know there's a 'move package' button now, but this very thread
demonstrates how obscure and inconvenient that is. There is no reason -
absolutely no reason at all - for PackMan to behave like this, with an
implicit, incorrect, but deep-rooted assumption that RISC OS software
will necessarily be installed to a fixed location on any filing system,
apart from sheer bloodymindedness and an apparent desire to spite users.

I never did get a meaningful response to this post:

http://www.riscosopen.org/forum/forums/5/topics/1396?page=4#posts-17230

Now I must include the standard disclaimer: I am *pro* RISC OS packages.
I think dependency management and update checking are both things which
need to hurry up and happen. But unlike most people, I take a
pragmatic, not a tribal, view of the two sides of the packaging debate,
and I don't let my appreciation (from the perspective of both a user and
a developer) of packaging's advantages get in the way of acknowledging
that the system we actually have is a total basket case.

--
__<^>__
/ _ _ \ I don't have a problem with God; it's his fan club I can't stand.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================

[Theo Markettos]

Dave Symes <da...@triffid.co.uk> wrote:
> Version 0.7 Beta (21 Sept 2012)
>
> It did work sort of once, but not for a long time now...
> For example it won't (Ever) update the Lists, erroring out with a 404.

Can you tell me which URLs those are?

> I never ever managed to get it, past or present to maintain Netsurf or
> dependencies.

NetSurf's daily builds were previously packaged, but they are no longer. So
not much that can be done about that for the moment.

> It still *appears* to work on DirSync and the Strong apps.
>
> It won't download and install the latest version of itself (Packman).
> (Never did).

What version of PackMan do you have? Is this related to the list URLs being
broken? If you have PackMan 0.6 it's very very old and you may wish to
try 0.7. (0.7.1 is coming shortly)

> I guess, who knows, I don't, the address/urls somewhere in for the package
> sources now uses, don't connect to the ones already in it. (There are two).
>
> And despite much searching can't find any info about list of sources Urls
> except Ri Pi of which I have no interest.

You're right, the description of package lists on http://packages.riscosopen.org/
are rather RPi-oriented. Now reworded to make clear that they're intended
for a more general audience.

Theo

[Theo Markettos]

Martin Bazley <martin...@blueyonder.co.uk> wrote:
> I will repeat this once again: the architecture underlying the present
> system of RISC OS packages is fundamentally wrong and needs a total
> rethink. PackMan's manner of operation is completely at odds with the
> operating system for which it is written. Whoever thought it was a good
> idea to abandon the standard, established system of installing by drag
> and drop?
>

> I never did get a meaningful response to this post:
>
> http://www.riscosopen.org/forum/forums/5/topics/1396?page=4#posts-17230

I too take a pragmatic view. We had a requirement:
1) To be able to introduce new RISC OS folks to existing software
2) To manage that software for people who didn't know RISC OS and were
unfamiliar how to install things (including dependencies, SysMerge,
BootMerge, etc)
3) To manage system updates that to machines that are already in the field.
4) That had an existing catalogue of software
5) ... and we didn't have much time or manpower

As I said last year in the thread you quoted, If you're able to write a
system that fulfills even a few of those goals then please do. If there's a
better solution out there that we can use, we're seriously interested.
Given we had a deadline, we had to go with something that already existed
with infrastructure in place. But if you've written a better way of doing
things, we're all ears.

Theo

[Theo Markettos]

Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Dave Symes <da...@triffid.co.uk> wrote:
> > Version 0.7 Beta (21 Sept 2012)
> >

> What version of PackMan do you have? Is this related to the list URLs being
> broken? If you have PackMan 0.6 it's very very old and you may wish to
> try 0.7. (0.7.1 is coming shortly)

D'oh, I clearly can't read.

> > It still *appears* to work on DirSync and the Strong apps.
> >
> > It won't download and install the latest version of itself (Packman).
> > (Never did).

0.7 is the latest official version so there's nothing to download. When
Alan is happy with 0.7.1 he'll put it in the repository and PackMan should
be able to update itself.

Theo

[Dave Symes]

In article <29984137...@blueyonder.co.uk>,

Martin Bazley <martin...@blueyonder.co.uk> wrote:
> > In article <5336fd2...@triffid.co.uk>,
> > Dave Symes <da...@triffid.co.uk> wrote:

> > > Ri Pi

> No, seriously, what is a "Ri Pi"? I can't imagine what that's supposed
> to stand for. The "Rispberry Pi"? Why do people keep calling it this?

[Snippy the other stuff, I agree BTW).

In my case, I guess, because I've seen it written so, a lot, I didn't
think about it and just wrote...

Ra Pi how about that then? ;-)

Personally I think the name stinks...

Back to the quest in hand thought.

So I've been to the RO Open site, I've opened one of the suppository list
urls (oh that was an interesting slip) repository urls, now what do I do
with it?

Dave

--

Dave Triffid

[Theo Markettos]

Dave Symes <da...@triffid.co.uk> wrote:
> So I've been to the RO Open site, I've opened one of the suppository list
> urls (oh that was an interesting slip) repository urls, now what do I do
> with it?

Iconbar menu of PackMan, find Sources. Add the URL of the repository to
that window (no need to download the file - it's just meant for PackMan).
Then do 'update lists' to refresh the packages available.

Theo

[Dave Symes]

In article <Y8y*mI...@news.chiark.greenend.org.uk>,

Sorry there is No Iconbar menu "Find Sources"

There is an "Advanced" > "Sources" that brings up a window "Sources for
packages".

I'd already added the...
http://packages.riscosopen.org/packages/ABCIndex.html
And
http://packages.riscosopen.org/thirdparty/SectionIndex.html

Unfortunately, as previously it doesn't work, erroring out with...

"Failed to update package list(s) Syntax error."

Dave

--

Dave Triffid

[Theo Markettos]

Dave Symes <da...@triffid.co.uk> wrote:
> Sorry there is No Iconbar menu "Find Sources"
>
> There is an "Advanced" > "Sources" that brings up a window "Sources for
> packages".
>
> I'd already added the...
> http://packages.riscosopen.org/packages/ABCIndex.html
> And
> http://packages.riscosopen.org/thirdparty/SectionIndex.html

Those are the links to the human-readable lists. You need to copy the URL
as quoted on the page:

http://packages.riscosopen.org/packages/pkg/programs-armv7
http://packages.riscosopen.org/packages/pkg/programs-armv5

I've just updated the wording to make that clearer, thanks for bringing it
up.

Theo

[Dave Symes]

In article <X8y*nX...@news.chiark.greenend.org.uk>,

And thanks to you for the above note illuminating my path to enlightenment.

All now done, various things auto updated (I started from scratch again).

A couple of aside thoughts...

I noticed that neither StrongEd nor Zap were in the lists, so do they have
package addresses somewhere else?

Thanks
Dave

--

Dave Triffid

[Tony Moore]

On 5 Apr 2013, Dave Symes <da...@triffid.co.uk> wrote:

[snip]

> I noticed that neither StrongEd nor Zap were in the lists, so do they
> have package addresses somewhere else?

StrongED, and many other applications, are in package list
http://www.riscpkg.org/pkg/Unstable . I don't know about Zap

Tony

[Alan]

On Thursday, 4 April 2013 20:41:52 UTC+1, Martin Bazley wrote:
> The following bytes were arranged on 4 Apr 2013 by Chris Johnson :
>

> > Dave Symes wrote:
>
> > It is shortsighted to dismiss all these packages out of hand. I think
> > the ultimate intention is for these package lists to become the first
> > port of call for RISC OS software.
>
> They'll have to knock some sense into the packaging system first. At
> present, the hassle of using, never mind setting up, PackMan vastly
> outweighs any theoretical benefits it may provide.

I don't find that - but then as the Author of PackMan I am biased.
Setting up really isn't that hard, no harder than most other RISC
OS applications. For me it's benefits have always outweighed it's
limitations.

>
> I will repeat this once again: the architecture underlying the present
> system of RISC OS packages is fundamentally wrong and needs a total
> rethink. PackMan's manner of operation is completely at odds with the
> operating system for which it is written. Whoever thought it was a good
> idea to abandon the standard, established system of installing by drag
> and drop?
>

An I repeat again I disagree that it is completely at odds with the
operation system for which is was written. Maybe the initial design
should have catered for Drag-and-drop, but I guess the idea was to
manage your disc for you. The underlying system was designed from
the start to allow for applications to placed anywhere on disc even
if it was not in the front-ends or encouraged.

> And I know there's a 'move package' button now, but this very thread
> demonstrates how obscure and inconvenient that is. There is no reason -
> absolutely no reason at all - for PackMan to behave like this, with an
> implicit, incorrect, but deep-rooted assumption that RISC OS software
> will necessarily be installed to a fixed location on any filing system,
> apart from sheer bloodymindedness and an apparent desire to spite users.

There was never any bloodymindedness or desire to spite users, the
whole thing was developed to help them find/install and maintain
packages. I didn't write the original system, but found it useful
and the restrictions on application placement did not bother me.
I wrote PackMan as I wanted to make a more friendly front-end than
RiscPkg.

The whole move-app feature shows there is no bloodymindedness on my
part. Although I didn't need it, there was a lot of people who
wanted to put things in other locations and they didn't like the
stubs idea, so this was to help them.

>
> I never did get a meaningful response to this post:
>
> http://www.riscosopen.org/forum/forums/5/topics/1396?page=4#posts-17230

Well I guess I'm the one who should have responded, but as I didn't
see it in the first place so there's not a lot I could do about that.

>
> Now I must include the standard disclaimer: I am *pro* RISC OS packages.
> I think dependency management and update checking are both things which
> need to hurry up and happen. But unlike most people, I take a
> pragmatic, not a tribal, view of the two sides of the packaging debate,
> and I don't let my appreciation (from the perspective of both a user and
> a developer) of packaging's advantages get in the way of acknowledging
> that the system we actually have is a total basket case.
>

I take a pragmatic, non-tribal view as well. We have a perfectly capable
packaging system which works well. I don't see any insurmountable
flaws in the original design of it, so I chose to work with it and
try to improve it.

There was much discussion over a year and quarter ago about an alternative
and I deliberately stood aside, just making comments on how the
current system worked to allow a better system to be produced. A I
said at the time I would be happy to use a new system. So again there
was no tribal view. Nothing came of it, so I returned to work on
improving my existing Packaging front-end.

I'm really sorry you seem to hate the current packaging system so
much and can't see any benefit to it at all. I personally do and
believe that at least a few other people find it useful.

Regards,
Alan

[Martin Bazley]

The following bytes were arranged on 5 Apr 2013 by Alan :

> Setting up really isn't that hard, no harder than most other RISC
> OS applications. For me it's benefits have always outweighed it's
> limitations.

As before, my extremely limited experience with PackMan precludes me
from making informed judgements about the friendliness of its behaviour
(as opposed to the friendliness of the back-end in general), but does it
do that thing the old !RiscPkg application did, requiring you to first
download a 'bootstrap' copy manually and use that to download another
copy via packaging, deleting the first copy afterwards? Cos that ain't
simple.

Most telling of your comments, I think, is this:

> An I repeat again I disagree that it is completely at odds with the
> operation system for which is was written.

Which is then swiftly followed by this:

> I guess the idea was to manage your disc for you.

Can you not see the glaring contradiction here? Linux 'manages your
disc for you'. Windows 'manages your disc for you'. RISC OS, thanks to
its application directories, single-user structure, absence of registry
and position-independence via <Obey$Dir>, has always taken pride in
allowing you to manage your OWN disc. Attempts to manage your disc for
you are therefore completely at odds with this. The assumption of fixed
locations undoes so many of the aforementioned advantages and regresses
the flexibility of RISC OS to something more primitive like Linux.

> The whole move-app feature shows there is no bloodymindedness on my
> part. Although I didn't need it, there was a lot of people who
> wanted to put things in other locations and they didn't like the
> stubs idea, so this was to help them.

But it doesn't help them. It's a sticking plaster over a deep-rooted
problem. Why on earth should an application ever go near an assumed
location, irrespective of whether you can at some theoretical future
point move it somewhere else or not?

To take the most trivial example, the assumption of fixed location quite
often results in directories being created which were not there before.
RiscPkg and, I believe, PackMan both install themselves in $.Apps.Admin,
for example. Nobody has an 'Admin' directory in 'Apps' unless LibPkg
put it there. But there's nothing you can do, at all, to stop it being
created. You can only install PackMan in there and then immediately
move it out, in which case you'll be left with an empty directory which
you didn't ask for and have to manually delete.

This is not the flexibility which users asked for. It's still a pain,
it's just you can now make it slightly less of a pain by manually adding
a few extra steps to every single installation process. Which is also a
pain. Need I remind you that the whole point of packaging is
automation?

Would it really have been so much effort to pop up a save box after
downloading an application, with that application's icon in it? You
know, like how every single RISC OS application ever does it?

And as for stubs...

Stubs were a stupid, stupid, stupid idea, for many reasons. I will
supply just one.

Firstly, some background. In this room, there are two computers - an
ARMini, on which I am currently typing, and an Iyonix. Both are
connected to a router and linked via ShareFS.

In the 'Internet' directory of the Iyonix, there are three stub
applications. Two of them - !LibPkg and !RiscPkg - were put there by
RiscPkg, and the other one - !PackMan - was, unsurprisingly, put there
by PackMan. This is relevant, because it seems the two applications
have different ideas of how to create a stub.

These stubs date from when I was using the Iyonix as a testbed for
packaging, and researching the creation of my own packages and looking
in great detail into how LibPkg worked. Ironically, it was this
practical experience that originally turned me against it; I'm not as
ill-informed as I may appear.

While I never installed any other software through RiscPkg, such was my
distaste for the system, those stubs were created and installed the
approved way, and thus the full RiscPkg backend works are present in the
Iyonix's !Boot, enabling those stubs to operate as officially intended.

Now, the ARMini. This doesn't have packaging of any sort installed. (I
think R-Comp intended it to be provided as an option, but judging by the
presence in !Packages.SetVars of lines such as "Set Packages$Apps
SCSI::ARMaster.$.Apps", they weren't very serious about it. ARMaster
is not the name of my, or anyone's, supplied flash drive.) Can you
guess what happens when I open the Iyonix's Internet directory over
ShareFS from the ARMini?

Filename ".!Boot" not recognised
Filing system or path ADFS: not present
Filename ".!Boot" not recognised

And sure enough, three non-functional stub applications. I can remotely
run - or at least boot, for heaven's sake - anything else I please, but
stub applications are totally useless for remote access. Which is
something which, in a household with many computers, I find myself doing
quite a lot.

Looking at the three autogenerated !Boot files, the RiscPkg ones are of
this form:

/ <LibPkg$Dir>.!Boot %*0

This relies on LibPkg$Dir having been set up in the boot sequence of the
machine, which is not, of course, guaranteed to be the same machine as
the one on which the application is installed on. Incorrect assumption
number one.

But PackMan is even worse:

/ADFS::Amery.$.Apps.Admin.!PackMan.!Boot %*0

Not only is this committing the cardinal sin of including an absolute
pathname in an application, the BeagleBoard version of RISC OS doesn't
even include ADFS!

Remote access is a use case you never considered at all, isn't it?

Why? Why would you wilfully abandon the perfectly good mechanisms RISC
OS has put in place since time immemorial, not even because it held any
advantages, but because it personally "did not bother" you?

If your ambition is to maintain a standard method of distributing RISC
OS software, which will have close to 100% user uptake, and widespread
developer acceptance, I'm afraid you're going to have to start sparing
some thoughts for other people.

--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later

[druck]

On 4 Apr 2013 Martin Bazley <martin...@blueyonder.co.uk> wrote:

> The following bytes were arranged on 4 Apr 2013 by Chris Johnson :

>> In article <5336fd2...@triffid.co.uk>,
>> Dave Symes <da...@triffid.co.uk> wrote:

>>> Ri Pi

> No, seriously, what is a "Ri Pi"? I can't imagine what that's supposed
> to stand for. The "Rispberry Pi"? Why do people keep calling it this?

Taking a massive leap of faith: how about RISC OS Pi, to distinguish
it from those running Linux?

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page - http://www.armclub.org.uk/32bit/

[Gavin Wraith]

In message <c5f2a737...@blueyonder.co.uk>

Martin Bazley <martin...@blueyonder.co.uk> wrote:

> Would it really have been so much effort to pop up a save box after
> downloading an application, with that application's icon in it? You
> know, like how every single RISC OS application ever does it?

I have just sent to Archive-Online my own thoughts about packaging
and I would be interested to hear Martin's reaction to them. In a
very small nutshell, my proposal is that the concept of "package"
conflates two different things, an "install" and an "update", and that
though that conflation may do no harm on other OSs, for RISC OS it
is better to keep the two separate. An "install" procedure needs to
know where to put its downloaded application, so it should put up
a save box if it succeeds in downloading the new application requested.
An "update" procedure, ideally triggered from an option in a menu
belonging to the application itself, already knows where the
application is. There is no reason why "install-servers" should be
conflated with "update-servers", nor why the two should not use quite
separate protocols. An update-server keeps, for each application it
serves, a list of patches; each one may be quite small. The author
of the application provides these, with a version difference
(e.g. x.xx -> y.yy), to the update-server. The user only clicks a
menu option to perform the update. The client-to-server message
specifies the application and version-number that is transmitting
the update-request, together with the new version-number requested.
The update-server uses this to send the right patch.

There are side-issues concerning the update of old applications -
an umbrella application !Update, with which applications can be
registered to be updated, is the most obvious solution. I do not
envisage the need for any stubs or specially named directories.
At the most it might be convenient for applications to contain a small
textfile called "version" or "!version" perhaps, containing version
information in an appropriate format and perhaps a list of URLs of
update-servers; in any case, something easily retro-fitted to old
applications.

I also mused about restartable downloads in case of interruption,
but that is orthogonal to my main point, which is: replace "package"
as a concept by the pair ("install", "update"). This separation is
useful at the server's end of things as well as the client's.

--
Gavin Wraith (ga...@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

[Andrew Wickham]

On 3 Apr, 23:28, Steve Fryatt <n...@stevefryatt.org.uk> wrote:
> On 3 Apr, Andrew Wickham wrote in message

>     <8a33d24f-df9e-4a84-aca9-0df06cc7a...@y14g2000vbk.googlegroups.com>:
>
[snip re StrongHelp$Dir settings]

>
> Not really, as anything PackMan has installed needs to stay where PackMan
> installs it so that it knows where it is -- IYSWIM.

IDYWYM and could live with PackMan reinstalling StrongHelp where it
thinks it should live whenever there is an update (and I could then
move the updated copy), but thanks your answer below I hope this will
not be necessary.

>
> The answer to to your question is yes, you can move it -- but you must do it
> from PackMan itself.  Load PackMan and open the list of packages (click
> Select on its iconbar icon). Select the StrongHelp package, click Menu over
> it and choose 'Package->Apps...'.  Click Menu again over the !StrongHelp
> icon in the Apps window that opens, then select 'Apps->Move->' and drag the
> resulting icon to where you want the app to live.

Sounds like I need to RTFM! or at least explore PackMan more
thoroughly. Thank you for the details, which I've cc'd to myself for
future reference!

>
> Doing it that way means that PackMan continues to know where StrongHelp is
> stored, so that it can continue to apply updates as they become available.
>
> [Coincidentally, I've just finished showing how to do exactly this at the
> WROCC meeting this evening...]
>

I really should get organised to come along - not far from
Huddersfield.

Andrew

[Theo Markettos]

Gavin Wraith <ga...@wra1th.plus.com> wrote:
> I have just sent to Archive-Online my own thoughts about packaging
> and I would be interested to hear Martin's reaction to them. In a
> very small nutshell, my proposal is that the concept of "package"
> conflates two different things, an "install" and an "update", and that
> though that conflation may do no harm on other OSs, for RISC OS it
> is better to keep the two separate. An "install" procedure needs to
> know where to put its downloaded application, so it should put up
> a save box if it succeeds in downloading the new application requested.

There's an issue with this: what if you want to install dozens of
applications at once (something people do regularly with package managers)?
Are you to be presented with four dozen save boxes? If not, you need some
kind of 'default' location, as in 'whatever, just do it'.

> An "update" procedure, ideally triggered from an option in a menu
> belonging to the application itself, already knows where the
> application is. There is no reason why "install-servers" should be
> conflated with "update-servers", nor why the two should not use quite
> separate protocols.
> An update-server keeps, for each application it
> serves, a list of patches; each one may be quite small. The author
> of the application provides these, with a version difference
> (e.g. x.xx -> y.yy), to the update-server.

Case in point: There have been 173 versions of the upstream Raspberry Pi
firmware. An x.xx to y.yy update requires enumerating for all x.xx and all
y.yy, in other words it's order N squared. If all 173 versions were
packaged that would be almost 30000 updates to store. Just for one package of
three files. And if you mean incremental patches, ie 1.00 -> 1.01, 1.01 ->
1.02, etc that's a lot of patches to download then you want to go from 1.00
to 5.40. Your installer would spend its life downloading and unpacking
updates only to throw away 90% of the contents.

Also, updates aren't just about replacing or adding files, sometimes files
must be removed too. So a conventional drag-over-the-top copy doesn't quite
suffice.

Whatever it is, the system must *scale*. Debian has 29000 packages. If you
come up with a system, would it work at that kind of size? OK, maybe 29000
isn't likely but perhaps 2900 or even 290.

> I also mused about restartable downloads in case of interruption,
> but that is orthogonal to my main point, which is: replace "package"
> as a concept by the pair ("install", "update"). This separation is
> useful at the server's end of things as well as the client's.

Restarting downloads is fairly straightforward, and I agree is something
that would be useful. I believe the libcurl library used by libpkg already
supports that, but we might not enable it. Though PackMan will retain
packages you already downloaded, so a download restart will only mean
re-downloading the package that was interrupted, not the whole lot.

Theo

[Tim Hill]

In article <mpro.mkss21...@ypical.nospam.invalid>, Fred Bambrough
<fred@[127.0.0.1]> wrote:
> In message <65f34937...@druck.org.uk> druck <ne...@druck.org.uk>

> wrote:

> > On 4 Apr 2013 Martin Bazley <martin...@blueyonder.co.uk> wrote:
> >

> > > The following bytes were arranged on 4 Apr 2013 by Chris Johnson :
> >
> > >> In article <5336fd2...@triffid.co.uk>, Dave Symes
> > >> <da...@triffid.co.uk> wrote:
> >
> > >>> Ri Pi
> >
> > > No, seriously, what is a "Ri Pi"? I can't imagine what that's
> > > supposed to stand for. The "Rispberry Pi"? Why do people keep
> > > calling it this?
> >

> > Taking a massive leap of faith: how about RISC OS Pi, to distinguish
> > it from those running Linux?

> ISTR someone suggesting ROPi. I'd never do that though.

I called mine RISCberryPi at one point, but it's a bit long. RORPi is
perhaps a better portmanteau abbreviation though ROSPi seems popular and
more 'natural' a word.

--
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/

Robin: "I guess you can never trust a woman." Batman: "You've made a hasty generalization, Robin. It's a bad habit to get into."

[News poster]

In message <d74ca8a9-f8d1-4cda...@googlegroups.com>

Alan <alan...@hotmail.com> wrote:

> On Thursday, 4 April 2013 20:41:52 UTC+1, Martin Bazley wrote:
> > The following bytes were arranged on 4 Apr 2013 by Chris Johnson :
> >
> > > Dave Symes wrote:
> >
> > > It is shortsighted to dismiss all these packages out of hand. I think
> > > the ultimate intention is for these package lists to become the first
> > > port of call for RISC OS software.
> >
> > They'll have to knock some sense into the packaging system first. At
> > present, the hassle of using, never mind setting up, PackMan vastly
> > outweighs any theoretical benefits it may provide.
>
> I don't find that - but then as the Author of PackMan I am biased.
> Setting up really isn't that hard, no harder than most other RISC
> OS applications. For me it's benefits have always outweighed it's
> limitations.

The other very important point is that the alternatives have
considerably more limitations.

1) No-one, to my knowledge, has written another package manager for RISC
OS, so trying to use that software to keep your disc image up to date is
going to be extremely difficult indeed.

2) There seem to be a few RISC OS users (probably suffering from OCD)
who have completely up to date software and Boot components. I am not
one of them. The only time I update Boot components is when I finally
get round to downloading the newest stable version of Netsurf which then
refuses to start until an updated blahblah has been added to Boot or
System.

In contrast my work PC and the Apple and Linux computers at home, update
themselves and 'organise' my hard disk for me. I don't feel a need to
know where the updated modules and programs have been placed.

3) The vast majority of (mobile) computing users don't give a monkeys
uncle how their hard drive is organised, and are not capable of doing it
even if they were interested. Anyone else out there with a
relative or friend using Windows with all their files saved to, and
'organised' on the desktop?

4) The only reason that my mothers computer is up to date in terms of OS
and software is because these updates take place (almost) automatically
via a package manager. The "almost" is that some types of updates
require the user to click a confirmation button on a dialogue. When my
mother was using RISC OS 4 updates were not an issue because there
weren't any.

5) The alternative to a package manager is for users to search the
cornucopia of RISC OS developer sites to try to find "an app of type x"
to add to their RPi hard disk image.

6) I don't think that a new or returning RISC OS user is going to find
using Boot "Install" or Sysmerge any easier (or harder) than using
Packman.
>
[snip]

>
> > And I know there's a 'move package' button now, but this very thread
> > demonstrates how obscure and inconvenient that is. There is no reason -
> > absolutely no reason at all - for PackMan to behave like this, with an
> > implicit, incorrect, but deep-rooted assumption that RISC OS software
> > will necessarily be installed to a fixed location on any filing system,
> > apart from sheer bloodymindedness and an apparent desire to spite users.
>
> There was never any bloodymindedness or desire to spite users, the
> whole thing was developed to help them find/install and maintain
> packages. I didn't write the original system, but found it useful
> and the restrictions on application placement did not bother me.
> I wrote PackMan as I wanted to make a more friendly front-end than
> RiscPkg.
>
> The whole move-app feature shows there is no bloodymindedness on my
> part. Although I didn't need it, there was a lot of people who
> wanted to put things in other locations and they didn't like the
> stubs idea, so this was to help them.
>

As one of the complainers from a year and a half ago I have to say I was
very pleased to find the option for moving default install location in
the menus of Packman when I got my RPi up and running. This additional
functionality is in no way hidden or in an obscure place. My thanks to
the developer for taking the effort to make the changes.

One last point regarding the UI's of package managers: none of the
package manager I have used (on any platform) have filled me with any
great enthusiasm. However, I have to admire the effort that has gone
into making reliable and simple to use 'software and update delivery
systems' that in the vast majority of cases just seem to work.

Cheers
Stan

--
An Iyonix, a Beagleboard xM and a RPi running RISC OS in Buskerud.

http://mistymornings.net

[Alan]

On Friday, April 5, 2013 3:19:51 PM UTC+1, Martin Bazley wrote:
> The following bytes were arranged on 5 Apr 2013 by Alan :
>
> > Setting up really isn't that hard, no harder than most other RISC
> > OS applications. For me it's benefits have always outweighed it's
> > limitations.
>
> As before, my extremely limited experience with PackMan precludes me
> from making informed judgements about the friendliness of its behaviour
> (as opposed to the friendliness of the back-end in general), but does it
> do that thing the old !RiscPkg application did, requiring you to first
> download a 'bootstrap' copy manually and use that to download another
> copy via packaging, deleting the first copy afterwards? Cos that ain't
> simple.

For PackMan you download the latest version of the software which is
fully functional and can be used immediately, but you still really
need to to install a packaged version and delete the old version.

As you say it's not entirely simple, but it shouldn't be beyond most
users. It's also a one off requirement to get the packaging system
going.

>
> Most telling of your comments, I think, is this:
>
> > An I repeat again I disagree that it is completely at odds with the
> > operation system for which is was written.
>
> Which is then swiftly followed by this:
>
> > I guess the idea was to manage your disc for you.
> Can you not see the glaring contradiction here? Linux 'manages your
> disc for you'. Windows 'manages your disc for you'. RISC OS, thanks to
> its application directories, single-user structure, absence of registry
> and position-independence via <Obey$Dir>, has always taken pride in
> allowing you to manage your OWN disc. Attempts to manage your disc for
> you are therefore completely at odds with this. The assumption of fixed
> locations undoes so many of the aforementioned advantages and regresses
> the flexibility of RISC OS to something more primitive like Linux.
>

Nope, I still can't see the glaring contradiction here. It doesn't change
how the programs work or makes them run in any way differently than
before. Any packaging system has to know where the things it's packaged
are if it's going to be able to update them. It doesn't stop them working
if you moved them with PackMan or from the filer.

>
> > The whole move-app feature shows there is no bloodymindedness on my
> > part. Although I didn't need it, there was a lot of people who
> > wanted to put things in other locations and they didn't like the
> > stubs idea, so this was to help them.
>
> But it doesn't help them. It's a sticking plaster over a deep-rooted
> problem.

But it does help them. It's not a sticking plaster over a deep rooted
problem, the underlying packaging system allows them to be moved without
any bodge or hack to the code.

> Why on earth should an application ever go near an assumed
> location, irrespective of whether you can at some theoretical future
> point move it somewhere else or not?

Because it gives a useful default and makes it easier to install. It's
not exactly difficult to move it to a new location. Haven't you ever
unpacked a zip file to one place then moved it to another?

>
> To take the most trivial example, the assumption of fixed location quite
> often results in directories being created which were not there before.
> RiscPkg and, I believe, PackMan both install themselves in $.Apps.Admin,
> for example. Nobody has an 'Admin' directory in 'Apps' unless LibPkg
> put it there. But there's nothing you can do, at all, to stop it being
> created. You can only install PackMan in there and then immediately
> move it out, in which case you'll be left with an empty directory which
> you didn't ask for and have to manually delete.
>

This is the kind of useability thing that can be improved, it doesn't
mean the whole idea is flawed. The next release of PackMan will allow
you to specify directories before downloading, but this is still not
the full drag-and-drop you require.

>
> This is not the flexibility which users asked for. It's still a pain,
> it's just you can now make it slightly less of a pain by manually adding
> a few extra steps to every single installation process. Which is also a
> pain. Need I remind you that the whole point of packaging is
> automation?

Well if it's slightly less of a pain - at least it's a step in the right
direction.

It is automating things for you, it's installing it and putting in the
dependencies and allowing you to update it easily after it has installed.

>
> Would it really have been so much effort to pop up a save box after
> downloading an application, with that application's icon in it? You
> know, like how every single RISC OS application ever does it?

It's much simpler to download them and move them of course, and as you
have said Graham's original intention was to install to fixed places
so it didn't arise.

It becomes more complicated when downloading multiple packages at once,
some of which do need to go into fixed locations. This doesn't mean
it's impossible or difficult though.

>
> And as for stubs...
>
> Stubs were a stupid, stupid, stupid idea, for many reasons. I will
> supply just one.

[snip your use case]

Stubs are not appropriate for your setup then. Nice of you to explain
why.

> Why? Why would you wilfully abandon the perfectly good mechanisms RISC
> OS has put in place since time immemorial, not even because it held any
> advantages, but because it personally "did not bother" you?

I've not abandoned any good mechanisms of RISC OS. I found I could work
with the packaging system as it was and found it useful and hoped others
would too.

> If your ambition is to maintain a standard method of distributing RISC
> OS software, which will have close to 100% user uptake, and widespread
> developer acceptance, I'm afraid you're going to have to start sparing
> some thoughts for other people.
>

This I do object too, I have spared a lot of thoughts for other people.
Why do you think I even bother to answer you at all. If I didn't care
I would ignore you entirely. I have been slowly improving the Packaging
front-end while taking into account comments from others.

It's not going to all-singing, all-dancing and perfect for everyone
ever. I just think it's worth striving to get it to be a useful tool
for installing software to help as many people as it can.

Regards,
Alan

[Martin Bazley]

The following bytes were arranged on 8 Apr 2013 by Alan :

> On Friday, April 5, 2013 3:19:51 PM UTC+1, Martin Bazley wrote:
> > The following bytes were arranged on 5 Apr 2013 by Alan :

[snip]

> For PackMan you download the latest version of the software which is
> fully functional and can be used immediately, but you still really
> need to to install a packaged version and delete the old version.
>
> As you say it's not entirely simple, but it shouldn't be beyond most
> users. It's also a one off requirement to get the packaging system
> going.

Wouldn't it be possible to automate this? I know packaging is supposed
to discourage/render obsolete applications shipping with bespoke
automated installers, but 'quis installiet ipsos installes'? I think I
would have implemented it something along the lines of the following:

User unzips !PackMan and drags and drops it somewhere.

User double-clicks on !PackMan.

PackMan's !Run file notices that <Packages$Dir> has not been set, and
runs an internal support program.

This secondary program pops up a window saying it's going to attempt to
install PackMan, are you quite sure you want to do this, etc.

User consents.

A basic, empty copy of the !Packages application is created inside
!Boot.Resources, copying some files (like sprites) from a directory kept
inside !PackMan for this purpose where necessary. This is then
Filer_Booted. If it turns out to already exist, the program assumes it
was all a big mistake and lets PackMan run normally (maybe the boot
process didn't complete properly or something).

Into the relevant structures inside !Packages are poked the requisite
runes to register the PackMan package as installed, with the registered
location of the !PackMan application initialised to the value of
<PackMan$Dir>.

PackMan continues running as normal and it's just like you'd installed
its package the normal way.

I guess the main way this could go wrong is if there's more than one
competing distribution of PackMan, so it initialises its source to the
wrong repository. Thanks to RPMs, I'd call that inevitable even if,
AFAIK, it hadn't already happened what with all the ROOL stuff.

> > Most telling of your comments, I think, is this:
> >
> > > An I repeat again I disagree that it is completely at odds with the
> > > operation system for which is was written.
> >
> > Which is then swiftly followed by this:
> >
> > > I guess the idea was to manage your disc for you.
> >
> > Can you not see the glaring contradiction here? Linux 'manages your
> > disc for you'. Windows 'manages your disc for you'. RISC OS, thanks to
> > its application directories, single-user structure, absence of registry
> > and position-independence via <Obey$Dir>, has always taken pride in
> > allowing you to manage your OWN disc. Attempts to manage your disc for
> > you are therefore completely at odds with this. The assumption of fixed
> > locations undoes so many of the aforementioned advantages and regresses
> > the flexibility of RISC OS to something more primitive like Linux.
> >
> Nope, I still can't see the glaring contradiction here. It doesn't change
> how the programs work or makes them run in any way differently than
> before.

In that case, I don't think we're going to get anywhere. It wouldn't
change how your software worked if you had to launch every program by
navigating to Resources:$.Resources.Switcher.HAL.OS_Byte76.Power.
NewReset.Apps.!Alarm, putting the clock forward to midnight on the first
full moon after the autumn equinox, spilling 4ccs of white mouse blood
into your keyboard, clicking on the Start button and searching for "My
Lord Azathoth", then tapping out the name of the application you want to
start in Morse code on the underside of your desk, but forgive me if I
think that having a system which can technically be said to be
functional isn't the only important thing around here.

Hyperbole, yes, but you get the drift. (Or maybe you don't.) The thing
which really rubs me up the wrong way about this system is the
*presumptiveness* of the whole thing, a feeling which your decision to
implement an option to move packages after the event in lieu of
replacing the lot with standard drag-and-drop did nothing to alleviate.
In fact, in many ways, the addition of the option to move applications
made me more annoyed, not less, because it felt as if you had listened
what was the single biggest objection to packaging by an overwhelming
majority of users and then deliberately tried to come up with a
solution which would comply with the letter of their demands while
ignoring the spirit. This is what I was thinking of earlier when I used
the words 'spite' and 'bloodymindedness'.

The fact remains, if most people (I don't know about you) were sitting
down to design an installer of RISC OS software, this is not at all how
they would do it. The RISC OS desktop just doesn't work that way, and
never has. Surely you can appreciate this - that, presuming a
completely fresh start, this is not the design that would evolve - even
if you also feel that the existing Linux-influenced paradigm is not
incompatible?

> > Why on earth should an application ever go near an assumed
> > location, irrespective of whether you can at some theoretical future
> > point move it somewhere else or not?
>
> Because it gives a useful default and makes it easier to install.

Useful defaults are one thing. Forced defaults are quite another.

> It's not exactly difficult to move it to a new location.

It's more difficult than just dragging it from one folder to another.
As with the installation of PackMan, the little details matter more than
I think you realise.

> Haven't you ever unpacked a zip file to one place then moved it to
> another?

I can't honestly say I have. Maybe if I change my mind rapidly, but
normally I use this dreadfully handy drag-and-drop interface which Acorn
just left lying around to drag files straight from within the zip to
their destination.

I'm not sure why you're trying to fight against this. Do you think
drag-and-drop has had its day?

> The next release of PackMan will allow you to specify directories
> before downloading, but this is still not the full drag-and-drop you
> require.

An incremental improvement, but again, I can only ask: Why not? What
kind of dreadful things will happen if you do implement full
drag-and-drop?

> > Would it really have been so much effort to pop up a save box after
> > downloading an application, with that application's icon in it? You
> > know, like how every single RISC OS application ever does it?
>
> It's much simpler to download them and move them of course, and as you
> have said Graham's original intention was to install to fixed places
> so it didn't arise.

When you say "simpler", do you mean simpler for you, or simpler for the
users? Only I can't imagine any possible way in which it could be
simpler for the users. Simpler for the newbies arriving from Linux,
perhaps, but if that's a good enough reason to change fundamental parts
of the OS, can I just put my vote in for a native bash-style command
line interpreter?

> It becomes more complicated when downloading multiple packages at once,
> some of which do need to go into fixed locations. This doesn't mean
> it's impossible or difficult though.

The RiscPkg format has a number of directories defined for locations
inside !Boot (although one known weakness here is that there's currently
no way to install things into Choices). For the moment you can just
search for applications the same way as you do for generating stubs, and
only produce a save box if it isn't in one of those directories.

This, however, touches on a rather major deficiency with the RiscPkg
format, which once again stems from its careless recycling of Linux
conventions: how do you install software which isn't an application? I
distribute several BASIC programs as individual files, usually with no
more than a ReadMe accompanying them. How would you package those, now
that the search-for-applications trick no longer works?

Come to think of it, that would break stubs as well. You could sort-of
imitate a stub of a single file by having an Obey file with a Filer_Run
in it, but we're getting deep into bodge territory here even by stub
standards.

How it *should* have been done was to have a 'payload' field in the
Control file, giving a list of relative pathnames of files and/or
directories in the zip which formed part of the 'installation'. Stuff
in System gets automatically merged with !System and so on without this
needing to be specified. Speaking of the System directory, it should be
using !SysMerge - the existing, defined, commonly understood method on
RISC OS - instead of trying to roll its own, which apart from anything
else would eliminate all those annoying conflicts. Needless to say,
this is also a problem caused by the creator's casual disregard for the
operating system he was ostensibly writing a package manager for. God,
I hate this format.

--
__<^>__ "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

[Grahame Parish]

On 09/04/2013 00:23, Martin Bazley wrote:
>
> How it *should* have been done was to have a 'payload' field in the
> Control file, giving a list of relative pathnames of files and/or
> directories in the zip which formed part of the 'installation'. Stuff
> in System gets automatically merged with !System and so on without this
> needing to be specified. Speaking of the System directory, it should be
> using !SysMerge - the existing, defined, commonly understood method on
> RISC OS - instead of trying to roll its own, which apart from anything
> else would eliminate all those annoying conflicts. Needless to say,
> this is also a problem caused by the creator's casual disregard for the
> operating system he was ostensibly writing a package manager for. God,
> I hate this format.
>

Could I humbly suggest that you design and write the system that you are
looking for rather than denigrate what others have done. If it can be
done better, let's see it.

Grahame.

[Chris Hughes]

In message <kk0k0n$n70$1...@speranza.aioe.org>

I agree, Martin lets see *your* version so we can rip it to pieces.

Especially since you have not even used the *current* version by your
own admission.


--
Chris Hughes
Come to the Wakefield RISCOS Computer Show - 20th April 2013
http://www.wakefieldshow.org.uk

[Alan]

On Tuesday, 9 April 2013 00:23:53 UTC+1, Martin Bazley wrote:
> The following bytes were arranged on 8 Apr 2013 by Alan :
>
> > On Friday, April 5, 2013 3:19:51 PM UTC+1, Martin Bazley wrote:
> > > The following bytes were arranged on 5 Apr 2013 by Alan :
>
>

This sounds like a very sensible plan.

[snip Hyperbole]

> Hyperbole, yes, but you get the drift. (Or maybe you don't.) The thing
> which really rubs me up the wrong way about this system is the
> *presumptiveness* of the whole thing, a feeling which your decision to
> implement an option to move packages after the event in lieu of
> replacing the lot with standard drag-and-drop did nothing to alleviate.
> In fact, in many ways, the addition of the option to move applications
> made me more annoyed, not less, because it felt as if you had listened
> what was the single biggest objection to packaging by an overwhelming
> majority of users and then deliberately tried to come up with a
> solution which would comply with the letter of their demands while
> ignoring the spirit. This is what I was thinking of earlier when I used
> the words 'spite' and 'bloodymindedness'.

Moving applications was always something that would have been needed
sooner or later in PackMan. It was easier to implement and could be
given to user faster than full drag and drop and I was hoping that
it would alleviate one of the main reasons some user did not want to
use PackMan. It was a pragmatic decision, not one made out of spite
or bloodymindedness.

>
> The fact remains, if most people (I don't know about you) were sitting
> down to design an installer of RISC OS software, this is not at all how
> they would do it. The RISC OS desktop just doesn't work that way, and
> never has. Surely you can appreciate this - that, presuming a
> completely fresh start, this is not the design that would evolve - even
> if you also feel that the existing Linux-influenced paradigm is not
> incompatible?

I can appreciate that some (maybe most) people may have designed it
in a completely different way, but nobody did so I took what was
available and set about working with it. I think something similar
could have come about, though probably with the drag-and-drop you
mention at the start, but the underlying structure would probably
be similar as there are universal things that any packaging system
has to do.

>
>
> > > Why on earth should an application ever go near an assumed
> > > location, irrespective of whether you can at some theoretical future
> > > point move it somewhere else or not?
>
> > Because it gives a useful default and makes it easier to install.
>
> Useful defaults are one thing. Forced defaults are quite another.

OK

>
> > It's not exactly difficult to move it to a new location.
>
>
> It's more difficult than just dragging it from one folder to another.
> As with the installation of PackMan, the little details matter more than
> I think you realise.

I actually do agree with you here. The problem is that, you need to
start with the big things first or you have nothing. Feedback and
ways of improving the user interface are always welcome, and that
includes things like clarifying help as well.

>
>
> > Haven't you ever unpacked a zip file to one place then moved it to
> > another?
>
> I can't honestly say I have. Maybe if I change my mind rapidly, but
> normally I use this dreadfully handy drag-and-drop interface which Acorn
> just left lying around to drag files straight from within the zip to
> their destination.

OK, it's obviously just me then. Of course you need to have made sure
you had SparkFS or SparkPlug or something seen by the filer first so
it's not 100% obvious what you do if you were a novice user.

>
> I'm not sure why you're trying to fight against this. Do you think
> drag-and-drop has had its day?

No, I don't think drag-and-drop has had its day. I admit I didn't think
it was needed to install a package though. It's used everywhere else
within PackMan and RiscPkg to copy and move applications, setup the package
database and create stubs though.

>
> > The next release of PackMan will allow you to specify directories
> > before downloading, but this is still not the full drag-and-drop you
> > require.
>
> An incremental improvement, but again, I can only ask: Why not? What
> kind of dreadful things will happen if you do implement full
> drag-and-drop?
>
> > > Would it really have been so much effort to pop up a save box after
> > > downloading an application, with that application's icon in it? You
> > > know, like how every single RISC OS application ever does it?
>
> > It's much simpler to download them and move them of course, and as you
> > have said Graham's original intention was to install to fixed places
> > so it didn't arise.
>
> When you say "simpler", do you mean simpler for you, or simpler for the
> users?

A bit of both, but mainly simpler for me to produce something to
help the users who really don't like the fixed places sooner.

> Only I can't imagine any possible way in which it could be
> simpler for the users. Simpler for the newbies arriving from Linux,
> perhaps, but if that's a good enough reason to change fundamental parts
> of the OS, can I just put my vote in for a native bash-style command
> line interpreter?

I still don't see how it changes the fundamentals of the OS. Do they
user on Linux still use the bash-style command line interpreter then
I thought even Linux had some sort of GUI nowadays.

>
> > It becomes more complicated when downloading multiple packages at once,
> > some of which do need to go into fixed locations. This doesn't mean
> > it's impossible or difficult though.
>
> The RiscPkg format has a number of directories defined for locations
> inside !Boot (although one known weakness here is that there's currently
> no way to install things into Choices). For the moment you can just
> search for applications the same way as you do for generating stubs, and
> only produce a save box if it isn't in one of those directories.

OK, I know you are not going to like it, but I really don't think a
Package manager should install things into choices. It should be
the applications responsibility to look after the Choices.

>
> This, however, touches on a rather major deficiency with the RiscPkg
> format, which once again stems from its careless recycling of Linux
> conventions: how do you install software which isn't an application? I
> distribute several BASIC programs as individual files, usually with no
> more than a ReadMe accompanying them. How would you package those, now
> that the search-for-applications trick no longer works?

You have to shove them in a hold all RISC OS application of some kind.
But it's true you can fix the path using the add path in the next
release, but even that's not a simple way of solving your problem.

Personally, I think if it's not just a module or documentation it
should be in a RISC OS application, but that's my preference and
I'm sure you will disagree.

>
> Come to think of it, that would break stubs as well. You could sort-of
> imitate a stub of a single file by having an Obey file with a Filer_Run
> in it, but we're getting deep into bodge territory here even by stub
> standards.

Yes, stubs are not useful in all cases.

>
> How it *should* have been done was to have a 'payload' field in the
> Control file, giving a list of relative pathnames of files and/or
> directories in the zip which formed part of the 'installation'.

I prefer to have the option to create the payload with drag and drop
into a directory I can then zip up.

One of my thought on how to implement proper drag and drop would
add a field to the control file saying what can be dragged though.

> Stuff
> in System gets automatically merged with !System and so on without this
> needing to be specified. Speaking of the System directory, it should be
> using !SysMerge - the existing, defined, commonly understood method on
> RISC OS - instead of trying to roll its own, which apart from anything
> else would eliminate all those annoying conflicts. Needless to say,
> this is also a problem caused by the creator's casual disregard for the
> operating system he was ostensibly writing a package manager for.

There is no interface to SysMerge available for other programs
to use so how could it use it.

> God,
> I hate this format.
>

I'd guessed.

Regards,
Alan

[Martin Bazley]

The following bytes were arranged on 9 Apr 2013 by Chris Hughes :

> In message <kk0k0n$n70$1...@speranza.aioe.org>
> Grahame Parish <maillis...@millers-way.net> wrote:

> > Could I humbly suggest that you design and write the system that you are
> > looking for rather than denigrate what others have done. If it can be
> > done better, let's see it.
>
> I agree, Martin lets see *your* version so we can rip it to pieces.

I probably shouldn't respond to ad hominems, but you seem awfully
certain that you wouldn't like any theoretical system created by me that
you haven't even heard of yet. May I ask exactly what you don't like
about the changes I have suggested, and why you don't recognise the
problems I have pointed out?

Not that you actually do have anything constructive to add, otherwise
you would already have answered the questions above. Such is the way of
Usenet. I'm wondering if I should just stop reading csa.* altogether,
it's so chock full of idiots and emotionally stunted five-year-olds. I
find one gets a much higher quality of debate on the web forums which a
large proportion of this newsgroup despises so intensely. The
temptation to leave Usenet in the past where it belongs, to slowly
dissolve in its own bile and bitterness, is a strong one.

> Especially since you have not even used the *current* version by your
> own admission.

I think I probably know considerably more about it than you do. I don't
just pluck these criticisms out of thin air - I spent a lot of time
researching the format and the workings of the back-end, and putting
together packages of my own.

Nobody has yet told me that any of my criticisms are factually wrong,
merely that they do not agree that the faults I have found in the
system are in fact faults.

--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later

( ( |_| ) )

[Martin Bazley]

The following bytes were arranged on 9 Apr 2013 by Alan :

> On Tuesday, 9 April 2013 00:23:53 UTC+1, Martin Bazley wrote:

> > I'm not sure why you're trying to fight against this. Do you think
> > drag-and-drop has had its day?
>
> No, I don't think drag-and-drop has had its day. I admit I didn't think
> it was needed to install a package though. It's used everywhere else
> within PackMan and RiscPkg to copy and move applications, setup the package
> database and create stubs though.

I can't think of any other way of installing software, whether that be
dragging it out of a zip file, dragging it off a floppy disc, or even
dragging it out of a NetSurf download window, which doesn't use drag and
drop. RISC OS has never really gone in for 'installer' programs in the
same way Windows did, which is mostly because its layout is considerably
less centralised than either that system or Linux.

What RiscPkg, and PackMan, are trying to be is essentially an
'installer', a concept which has always been somewhat unfamiliar to the
RISC OS desktop. I have voiced before, I think, my objection to the
SysVars and Sprites directories, because they represent an assumption of
much greater centralisation than has historically been the case.
Indeed, the whole thing smacks of trying to establish a 'registry'.

At best, all you need is an option to ask the user if they want the
application to be booted and/or run on startup. Ideally, this should
integrate into the existing, defined methods of doing so - see comments
about SysMerge later.

> > Only I can't imagine any possible way in which it could be
> > simpler for the users. Simpler for the newbies arriving from Linux,
> > perhaps, but if that's a good enough reason to change fundamental parts
> > of the OS, can I just put my vote in for a native bash-style command
> > line interpreter?
>
> I still don't see how it changes the fundamentals of the OS. Do they
> user on Linux still use the bash-style command line interpreter then
> I thought even Linux had some sort of GUI nowadays.

There is a certain kind of Linux user who looks down their nose at
anybody who can't operate the entire system from a text-only terminal.
I'm not sure why - surely the last thirty years of user interface design
progress happened for a reason? - but how much bash syntax you know is a
measure of your social class on some Linux forums.

Besides which, there are still alarmingly large parts of the system
which are only accessible from a terminal, and even many GUI components
are designed to be mere front-ends to bash commands or fancy editors of
conf files.

> > (although one known weakness here is that there's currently no way
> > to install things into Choices)
>

> OK, I know you are not going to like it, but I really don't think a
> Package manager should install things into choices. It should be
> the applications responsibility to look after the Choices.

And I know you're not going to like this, but unfortunately some
applications *do* install things into Choices. StrongED, and its
!StrED_cfg application, is the most obvious example here. I think Zap
has an equivalent, too.

Looking at how you've packaged StrongED, it seems !StrED_cfg is just
dumped in the Apps.Text directory along with !StrongED. This will
technically work, as this is one of the places StrongED will search for
it if it fails to find it in Choices, but it really belongs in Choices.

> > This, however, touches on a rather major deficiency with the RiscPkg
> > format, which once again stems from its careless recycling of Linux
> > conventions: how do you install software which isn't an application? I
> > distribute several BASIC programs as individual files, usually with no
> > more than a ReadMe accompanying them. How would you package those, now
> > that the search-for-applications trick no longer works?
>
> You have to shove them in a hold all RISC OS application of some kind.
> But it's true you can fix the path using the add path in the next
> release, but even that's not a simple way of solving your problem.
>
> Personally, I think if it's not just a module or documentation it
> should be in a RISC OS application, but that's my preference and
> I'm sure you will disagree.

But this is exactly my point. What if it *is* just a module or
documentation? If it's a module then I guess it probably goes in
System, but documentation might go in the Manuals directory, or even in
the same directory as the app to which it pertains.

There are some things which application holders simply cannot solve.
Take another thing I distribute a lot of: Doom levels. These are things
which want close to the Doom application, don't want in any old place on
your hard disc, can't be stubbed, aren't applications themselves, and
could in no conceivable way be converted to applications. Oh, and they
mostly come in pairs of files: LEVELNAME/WAD and LEVELNAME/TXT, with the
latter containing documentation. Can you explain how PackMan would
install those? I'm genuinely quite interested, working on the
assumption that the downloads on my website will sooner or later be
converted to some sort of package format.

You could just say that some things shouldn't be packaged, but you've
got to draw the line somewhere. You offer StrongED mode files, for
example. Besides which, automatic update checking is a rather useful
thing to have for things other than software.

> > How it *should* have been done was to have a 'payload' field in the
> > Control file, giving a list of relative pathnames of files and/or
> > directories in the zip which formed part of the 'installation'.
>
> I prefer to have the option to create the payload with drag and drop
> into a directory I can then zip up.
>
> One of my thought on how to implement proper drag and drop would
> add a field to the control file saying what can be dragged though.

Basically the same thing. I wouldn't describe the process of creating a
package as being as simple as dragging and dropping into a directory -
you have to write a Control file anyway, and a lot of its fields are
compulsory, so what's one more?

This would also solve the oddity (from a RISC OS perspective) of keeping
most things in a subdirectory calls Apps.Category, which is a hangover
from the days when RiscPkg literally expected you to install everything
into subdirectories of Apps. The simplest option would be to define
everything in the package root which wasn't a reserved name as part of
the installation, although keeping it in a subdirectory would eliminate
the small possibility of clashes. The end result would be to make the
process of creating a package slightly simpler than it is now.

One thing which I definitely want to see go away is the Paths file.
There are just so many places like that where RiscPkg should have been
designed with position independence in mind from the very beginning but
so clearly wasn't.

A useful feature for the corner cases would be to allow installation to
be (optionally) partially scripted by the package itself - another
feature I would have built in from the beginning. Two executable files
(or applications!) with reserved names, one to be executed before, and
one to be executed after, would cover most cases. They could even keep
support files in the package, safe in the knowledge that if it doesn't
appear in the 'Payload' field, PackMan won't try to install it.

Hell, if the 'Payload' field was blank, you could distribute 'virtual'
packages which performed tasks instead of physically installing stuff!
That would also allow for Linux-style 'manifest' packages, which you
'installed' to add repositories to the system, in place of the existing
rather clunky method.

I'm wandering off of RiscPkg and onto the realms of designing my own
manager here, I think. I am very tempted, let it be known, to do
exactly that. Maybe this summer...

> There is no interface to SysMerge available for other programs
> to use so how could it use it.

Technically, there is, at least partially - see below.

But that aside, I think this is symptomatic of the whole problem with
RiscPkg. It tried to impose itself on, rather than integrate itself
with, RISC OS.

How do you think packages became so successful on Linux? They were
developed, adopted and promoted by the system developers themselves.
Red Hat distribute all their software through RPMs. A package manager
is not an add-on to the system - it *is* part of the system.

The fact is, I think RiscPkg would be a lot better if it had made a more
serious effort to cooperate with RISC OS, rather than trying to change
things from outside. A constant refrain in my criticism of it is that
it started from the assumption that all RISC OS concepts could be
expressed in terms of Linux ones, when in fact both the installation of
software and the changing of the boot sequence work very differently
indeed.

One of the big hurdles in both cases was that Acorn had already written
tools to install software (the various Merges) and change the boot
sequence (the Boot configure tools), and that these were the only
approved ways of doing it. RiscPkg attempted to circumvent this by
effectively setting up an entire shadow boot sequence which it could
control itself, but this caused friction where the two met, as in the
case of installing modules into !System.

I'd like packages to be part of RISC OS, in the same way they're part of
Linux, which means biting the bullet and stopping dancing around issues
like these. Linux's boot sequence, not to mention application
launchers, work differently and have different interfaces (and, in some
cases, even have defined interfaces at all), and so these problems don't
arise. RiscPkg assumed that, just because it wasn't a problem on Linux,
it wouldn't be a problem on RISC OS. This assumption, in many different
guises, is the cause of all its problems.

The good news is that, thanks to ROOL, the potential for cooperation is
unprecedented. I think a programmatic interface to some of the
configuration tools would have been a necessity sooner or later, but now
we can define it ourselves! I raised this very point on the ROOL forums
a year ago:

http://www.riscosopen.org/forum/forums/2/topics/869

In fact, I am rather tempted to take up this particular challenge myself
- I need the excuse to get into OS development, and this looks like a
nice high-level point to jump in.

Interestingly, it appears that there is a more or less complete
programmatic interface for the 'Look at', 'Add to Apps' and 'Run'
windows (see section 5.2):

http://www.marutan.net/wikiref/Acorn%20Registered%20Developer%20REFERNC/RO4/API/HTML/CONFIGUR.HTM

This is what should have been used in place of SysVars, Sprites and all
those star commands in !Packages. Unless it isn't important for an
application to be booted, of course, which it won't be for most
non-command-line applications.

And some programs - particularly graphics programs or text editors - may
try to claim filetypes which the user doesn't want them to and/or
conflict with each other, making the initialisation of their SysVars
strictly a matter of personal preference. (How many programs on your
disc claim the JPEG filetype? I think I have at least five.) Another
not-so-uncommon case which the design should have taken into account,
but didn't because it simply doesn't arise on Linux.

[Theo Markettos]

Martin Bazley <martin...@blueyonder.co.uk> wrote:
> I can't think of any other way of installing software, whether that be
> dragging it out of a zip file, dragging it off a floppy disc, or even
> dragging it out of a NetSurf download window, which doesn't use drag and
> drop. RISC OS has never really gone in for 'installer' programs in the
> same way Windows did, which is mostly because its layout is considerably
> less centralised than either that system or Linux.

RISC OS has, in the cases where it's more complicated than one-app drag and
drop. I'm thinking of things like the ROOL C/C++ suite (not entirely sure
why) and Impression (need to do a user registration step and key your floppy
with the user ID).

Having two modes to install:
Automatic - Just Do It, I don't care too much where it goes
Manual - I want to set the location (by drag and drop)

isn't too far removed from the 'fast' and 'custom' install methods of
Windows installers. Though not railroading the user as an 'Install Wizard'
often feels like.

One thing PackMan currently doesn't address is the need to ask additional
questions on installation - in fact, the whole concept of pre/post-copy
operations are alien to it. Which is something that makes life difficult in
some circumstances (eg doing basic configuration, or more complex upgrades
than copying files).

> What RiscPkg, and PackMan, are trying to be is essentially an
> 'installer', a concept which has always been somewhat unfamiliar to the
> RISC OS desktop. I have voiced before, I think, my objection to the
> SysVars and Sprites directories, because they represent an assumption of
> much greater centralisation than has historically been the case.
> Indeed, the whole thing smacks of trying to establish a 'registry'.

I admit I'm not particularly keen on SysVars and Sprites.

> At best, all you need is an option to ask the user if they want the
> application to be booted and/or run on startup. Ideally, this should
> integrate into the existing, defined methods of doing so - see comments
> about SysMerge later.

That sounds like a nice idea. There's one awkward aspect - that booting
piles of applications causes lots of random file reads, which tends to
thrash disc (and flash) quite a lot and thus be slow - but I'm sure there
are ways to address that.

> There is a certain kind of Linux user who looks down their nose at
> anybody who can't operate the entire system from a text-only terminal.
> I'm not sure why - surely the last thirty years of user interface design
> progress happened for a reason? - but how much bash syntax you know is a
> measure of your social class on some Linux forums.

Part of the problem is there are so many wretched GUIs each with a
completely different configuration UI. I can't tell people how to change
something on, say, Fedora, because I haven't used it for years. But the
configuration files and the commands tend to stay the same across all GUIs
and all distros, so are easier to remember.

Also it's feasible to manage conf files when there is no GUI (eg over SSH to
my router, which has 16MB RAM) which doesn't follow for graphical tools
(though web-based interfaces sometimes help)

> And I know you're not going to like this, but unfortunately some
> applications *do* install things into Choices. StrongED, and its
> !StrED_cfg application, is the most obvious example here. I think Zap
> has an equivalent, too.

This is a bit of a problem. I have nothing against an app in Choices - it's
a good way to keep settings together. But Choices is carefully designed to
cope with being multiple overlapping directories (multi-user, network
administrated, different hardware etc), and it would be unfortunate to
prevent that. So the instructions of random software to 'put this app in
Choices' are actually breaking this design. Possibly one way forward is for
apps to have an internal default set of choices (eg internal !StrED_cfg),
and an addition to the !Run file to check for a suitable directory in
Choices and copy in the default if not found on first run.

Putting random executable code in Choices (eg Zap modules) is one I'm less
happy about.

Running things on boot is a different issue, and arguably one that only
shares some degree of overlap with Choices. I'm less worried about that,
though the Paths file allows these to be adjusted to install in the 'system'
area of Choices not the 'user' one.

> But this is exactly my point. What if it *is* just a module or
> documentation? If it's a module then I guess it probably goes in
> System, but documentation might go in the Manuals directory, or even in
> the same directory as the app to which it pertains.

One thing RISC OS doesn't really do well is how to deal with command line
stuff. If you install it in !Boot.Library, where does the documentation go?
If you put it in a dummy application, it's confusing because it doesn't do
anything useful when you double click it, and it needs to be filer-booted
before you can run the command.

So if it's a random document (eg the csa.* FAQ) it might go in Manuals or
Documents or something. If it's documentation pertaining to an app, I'd put
it inside the app or at the same level as the app.

> There are some things which application holders simply cannot solve.
> Take another thing I distribute a lot of: Doom levels. These are things
> which want close to the Doom application, don't want in any old place on
> your hard disc, can't be stubbed, aren't applications themselves, and
> could in no conceivable way be converted to applications. Oh, and they
> mostly come in pairs of files: LEVELNAME/WAD and LEVELNAME/TXT, with the
> latter containing documentation. Can you explain how PackMan would
> install those? I'm genuinely quite interested, working on the
> assumption that the downloads on my website will sooner or later be
> converted to some sort of package format.

In that case, I might put !Doom in Apps.Games.Doom.!Doom and then put levels
in Apps.Games.Doom.Levels (subdivided if necessary). The alternative would
be to put them inside the !Doom app, but that depends on !Doom automatically
finding levels inside itself, or a means of opening that subdirectory of the
app (eg, for documentation, a suitable !Help obey file)

How this works if the packager of !Doom hasn't anticipated 'other bits'
coming with it, I'm not sure. Clearly we wouldn't want the filesystem
divided by type (a la /usr/bin, /usr/lib, /usr/share/doc, though I
understand why multi-user multi-architecture Unix has those)

> This would also solve the oddity (from a RISC OS perspective) of keeping
> most things in a subdirectory calls Apps.Category, which is a hangover
> from the days when RiscPkg literally expected you to install everything
> into subdirectories of Apps. The simplest option would be to define
> everything in the package root which wasn't a reserved name as part of
> the installation, although keeping it in a subdirectory would eliminate
> the small possibility of clashes. The end result would be to make the
> process of creating a package slightly simpler than it is now.

That's possible... like the way current zipfiles have things like:
!MyApp
!!Readme1st
Readme/html
Examples
Plugins
Manual

Possibly put the whole lot into a directory and install it somewhere, where
the default might be Apps.Category.MyApp if you didn't specify anywhere else.

> One thing which I definitely want to see go away is the Paths file.
> There are just so many places like that where RiscPkg should have been
> designed with position independence in mind from the very beginning but
> so clearly wasn't.

Umm.. the Paths file is what indicates where things are to go - how to move
apps around and RiscPkg/PackMan still be able to find them. How would you
achieve this otherwise? If you do it by system variables (<MyApp$Dir>) you
upgrade whichever copy of the app has been Filer_Booted, even that
one on the floppy you opened yesterday. The Paths file is the one part that
implements the flexibility people are so requesting.

> A useful feature for the corner cases would be to allow installation to
> be (optionally) partially scripted by the package itself - another
> feature I would have built in from the beginning. Two executable files
> (or applications!) with reserved names, one to be executed before, and
> one to be executed after, would cover most cases. They could even keep
> support files in the package, safe in the knowledge that if it doesn't
> appear in the 'Payload' field, PackMan won't try to install it.

Care is required here, because one use of the current system is doing
non-RISC OS installs. The GCCSDK autobuilder compiles and constructs
packages on Unix. For example, it builds a nightly Raspberry Pi ROM package
and puts it on the ROOL website. This is a lot easier than trying to drive
RISC OS as a server (tell me how many datacentres have RISC OS servers for
starters). Being able to install cross-platform is a useful next step,
because it means it's possible to autobuild disc images too.

Also, uninstallation comes for free with LibPkg - it records which files you
copy and so can reverse the process. Would installs by scripting cover
that, or would you have to manually handle it (and probably get it wrong)?

But I agree, there will sometimes be operations beyond the 'just copy these
files to install' that's all PackMan does at the moment, and doing those
would be useful.

> Hell, if the 'Payload' field was blank, you could distribute 'virtual'
> packages which performed tasks instead of physically installing stuff!
> That would also allow for Linux-style 'manifest' packages, which you
> 'installed' to add repositories to the system, in place of the existing
> rather clunky method.

Interesting idea. PackMan 0.7.1 makes it slightly easier because there are
radio buttons to enable/disable various sources, but I agree the repository
architecture needs some further thought. One reason why Debian et al tend
to have few repositories is it makes the dependencies manageable, which is
something a more distributed repository system would have to consider.

> I'm wandering off of RiscPkg and onto the realms of designing my own
> manager here, I think. I am very tempted, let it be known, to do
> exactly that. Maybe this summer...

Can I encourage you to seriously consider that? :)
Particularly if we can end up with one manager that works better than what
we have at the moment, rather than two (or three) which work in half the
cases and ignore the rest?

> The fact is, I think RiscPkg would be a lot better if it had made a more
> serious effort to cooperate with RISC OS, rather than trying to change
> things from outside. A constant refrain in my criticism of it is that
> it started from the assumption that all RISC OS concepts could be
> expressed in terms of Linux ones, when in fact both the installation of
> software and the changing of the boot sequence work very differently
> indeed.

I agree that there's a gulf between 'what the system is theoretically
capable of' and 'what the GUI makes obvious it can do today'. Developers
see the former, users the latter.

The caveats being:
* Scale, scale and more scale. It needs to cope with installing and
upgrading full systems with hundreds or thousands of packages, not
painstakingly doing it one at a time.
* It needs to make life easy for the first-time user, not just the RISC OS
guru who has been using it for 25 years.
* It needs to be accepted by developers too

> The good news is that, thanks to ROOL, the potential for cooperation is
> unprecedented. I think a programmatic interface to some of the
> configuration tools would have been a necessity sooner or later, but now
> we can define it ourselves! I raised this very point on the ROOL forums
> a year ago:
>
> http://www.riscosopen.org/forum/forums/2/topics/869
>
> In fact, I am rather tempted to take up this particular challenge myself
> - I need the excuse to get into OS development, and this looks like a
> nice high-level point to jump in.

If you have a chance to look at that, it would be most interesting.
Particularly if it can integrate into what we already have (eg come up with
how to transform Sprites and SysVars into whatever favoured form you work
out, so we can just install the packages we already have but in a different
way, without having to re-package them all).

> And some programs - particularly graphics programs or text editors - may
> try to claim filetypes which the user doesn't want them to and/or
> conflict with each other, making the initialisation of their SysVars
> strictly a matter of personal preference. (How many programs on your
> disc claim the JPEG filetype? I think I have at least five.) Another
> not-so-uncommon case which the design should have taken into account,
> but didn't because it simply doesn't arise on Linux.

Indeed, this is an issue that is unresolved. If you have any thoughts, I'd
be most interested...

Theo

[spampling]

In article <f58cb039...@blueyonder.co.uk>,

Martin Bazley <martin...@blueyonder.co.uk> wrote:
> I'm wondering if I should just stop reading csa.* altogether,
> it's so chock full of idiots and emotionally stunted five-year-olds.

Why does the specific post destination matter?
You have the same argument, with slightly different phraseology in the
responses, going on in the ROOL forums.
The patient response by the developer is that each version changes things
in response to specific points raised, however sometimes no amount of
change seems to satisfy.

My two pennorth - it's getting there. Not the finished article, but I
suspect that the developer would agree with me there, but it does work
well enough that newbies can install packages quickly and with
certainty.

--

Steve Pampling

[Martin Bazley]

I can't post much more because I seriously need to finish coursework and
start revising, and I think the discussion is approaching its conclusion
anyway. But anyway, here are some responses to a few points raised.

The following bytes were arranged on 9 Apr 2013 by Theo Markettos :

> Martin Bazley <martin...@blueyonder.co.uk> wrote:

[snip]

> Automatic - Just Do It, I don't care too much where it goes
> Manual - I want to set the location (by drag and drop)

Having an 'Automatic' mode (equivalent to what we have now) would solve
the edge case of 'but what if you want to install three hundred packages
all at the same time?'

I think an optional field giving the default installation location would
be useful in the case you raise later of autobuilding a disc image, and
it would make more sense than having to define a new entry in the Paths
file for every location in which ROOL want to put stuff. (A whole bunch
of extra default paths like 'RO500Hook' and 'Utilities' were added to
the last revision of the Policy Manual in an attempt to overcome exactly
this problem.)

> > At best, all you need is an option to ask the user if they want the
> > application to be booted and/or run on startup. Ideally, this should
> > integrate into the existing, defined methods of doing so - see comments
> > about SysMerge later.
>
> That sounds like a nice idea. There's one awkward aspect - that booting
> piles of applications causes lots of random file reads, which tends to
> thrash disc (and flash) quite a lot and thus be slow - but I'm sure there
> are ways to address that.

That's the user's problem. If you shovel a load of stuff into your boot
sequence, you will have a slow boot sequence! This is one reason - the
other being the filetype claim conflicts business - why such things
should be strictly optional.

The most the manager should do is recommend that certain packages are
automatically booted, in the case of command line programs which aren't
much use otherwise. But this isn't really appropriate for most normal
applications.

I think the advantages in ease of maintaining your boot sequence, and in
neatness of integration into RISC OS, outweigh the theoretical
performance gains from essentially amalgamating the !Boot files of tens
of applications into one large Obey file.

BTW, I recently cleaned up the boot sequence of my RiscPC properly for
the first time in ages. I discovered a whole bunch of stuff I had added
to the 'Look at' menu when it was also in 'Run' and/or 'Add to Apps',
both of which do the same thing, and also some stuff which I couldn't
even remember why I'd put there. While I was at it, I cleared a lot of
junk out of my Resources directory too. The performance gain was quite
pleasing.

Ooh, Add to Apps - something else the package manager could offer as an
option. This is all based on existing technology, by the way - Acorn
seemed to have intended the interface used by Configure to be used by
third party installers such as, say, a package manager, but it all got
rather lost after Phoebe was cancelled.

> > And I know you're not going to like this, but unfortunately some
> > applications *do* install things into Choices. StrongED, and its
> > !StrED_cfg application, is the most obvious example here. I think Zap
> > has an equivalent, too.
>
> This is a bit of a problem. I have nothing against an app in Choices - it's
> a good way to keep settings together. But Choices is carefully designed to
> cope with being multiple overlapping directories (multi-user, network
> administrated, different hardware etc), and it would be unfortunate to
> prevent that. So the instructions of random software to 'put this app in
> Choices' are actually breaking this design.

Isn't this why we have <Choices$Write>?

> Possibly one way forward is for apps to have an internal default set
> of choices (eg internal !StrED_cfg), and an addition to the !Run file
> to check for a suitable directory in Choices and copy in the default
> if not found on first run.

Wishful thinking on the same level as hoping users will change the way
they use RISC OS, I'm afraid. Like it or not, packaging got here last,
and it's got to work with whatever predated it.

> > But this is exactly my point. What if it *is* just a module or
> > documentation? If it's a module then I guess it probably goes in
> > System, but documentation might go in the Manuals directory, or even in
> > the same directory as the app to which it pertains.
>
> One thing RISC OS doesn't really do well is how to deal with command line
> stuff. If you install it in !Boot.Library, where does the
> documentation go?

ROL did actually try and solve that one, with a defined system of 'Help'
subdirectories, which I think you could invoke with *help <filename>.

> > There are some things which application holders simply cannot solve.
> > Take another thing I distribute a lot of: Doom levels. These are things
> > which want close to the Doom application, don't want in any old place on
> > your hard disc, can't be stubbed, aren't applications themselves, and
> > could in no conceivable way be converted to applications. Oh, and they
> > mostly come in pairs of files: LEVELNAME/WAD and LEVELNAME/TXT, with the
> > latter containing documentation. Can you explain how PackMan would
> > install those? I'm genuinely quite interested, working on the
> > assumption that the downloads on my website will sooner or later be
> > converted to some sort of package format.
>
> In that case, I might put !Doom in Apps.Games.Doom.!Doom and then put levels
> in Apps.Games.Doom.Levels (subdivided if necessary). The alternative would
> be to put them inside the !Doom app, but that depends on !Doom automatically
> finding levels inside itself, or a means of opening that subdirectory of the
> app (eg, for documentation, a suitable !Help obey file)

If I could just hijack your own 'scale' argument for a moment, what
happens if you download all the levels from my site (quite
understandable, seeing as most of my ones are part of a set)? And we
can assume that !Doom has already been installed somewhere which almost
certainly isn't where the package manager thinks it is.

I'm a bit out of my depth here, because I don't know how PackMan
implements the moving of packages internally. If a package has more
than one application in it, can you move the two to different locations?
Can you move things other than applications? Does it work at the
application level, or at the file level? Graham once told me that
LibPkg works at the file level and doesn't really understand
applications, but does this mean you'd have to define every single item
beneath a directory as moved?

As it currently stands, however, downloading individual files - for
which you usually care even more than for applications exactly where
they are installed - is either tedious or impossible.

> Possibly put the whole lot into a directory and install it somewhere, where
> the default might be Apps.Category.MyApp if you didn't specify anywhere else.

I'd like to have the option to discard the ReadMe files (which are
usually just trivial installation instructions or copies of the !Help
file anyway) and just copy the application without creating a directory
especially for it, though. I don't always want everything in a zip. I
suspect configurable selective ignoring of zip contents would be asking
a bit much of any package manager, though.

One idea which might be worth pursuing is providing an option to choose
between creating a new directory or saving multiple files out of the
same save box (denoted by the unfortunately-named 'package' icon).

> > One thing which I definitely want to see go away is the Paths file.
> > There are just so many places like that where RiscPkg should have been
> > designed with position independence in mind from the very beginning but
> > so clearly wasn't.
>
> Umm.. the Paths file is what indicates where things are to go - how to move
> apps around and RiscPkg/PackMan still be able to find them. How would you
> achieve this otherwise? If you do it by system variables (<MyApp$Dir>) you
> upgrade whichever copy of the app has been Filer_Booted, even that
> one on the floppy you opened yesterday. The Paths file is the one part that
> implements the flexibility people are so requesting.

The Paths file is the reason everything currently gets installed in
Apps.

You need some sort of machine-editable database to keep track of where
applications have been installed, yes, but Paths isn't it.
Theoretically, the current package format allows for you to define new
entries in the Paths file to map your own custom zip subdirectories into
fixed locations of your choice, which is a solution to a problem
absolutely nobody has. There should be a small number of hardcoded
paths, to deal with the awkward stuff in !Boot like <Choices$Write> and
handle the interfaces to the Merges, and everything else can go wherever
the user demands.

> Care is required here, because one use of the current system is doing
> non-RISC OS installs. The GCCSDK autobuilder compiles and constructs
> packages on Unix. For example, it builds a nightly Raspberry Pi ROM package
> and puts it on the ROOL website. This is a lot easier than trying to drive
> RISC OS as a server (tell me how many datacentres have RISC OS servers for
> starters). Being able to install cross-platform is a useful next step,
> because it means it's possible to autobuild disc images too.

I think it's a case of either/or here, unless you allow for packages to
come with both 'native' and 'cross-install' scripts.

> Also, uninstallation comes for free with LibPkg - it records which files you
> copy and so can reverse the process. Would installs by scripting cover
> that, or would you have to manually handle it (and probably get it wrong)?

This was something I was slightly worried about. I guess the only way
would be to allow for uninstallation scripts as well, but then you'd
have to find a place to keep them, to speak nothing of trusting
developers to write failsafe scripts which could cope with undoing
anything the user did in the intervening five years, and which probably
don't get tested nearly as thoroughly as the installation ones to boot.

> > And some programs - particularly graphics programs or text editors - may
> > try to claim filetypes which the user doesn't want them to and/or
> > conflict with each other, making the initialisation of their SysVars
> > strictly a matter of personal preference. (How many programs on your
> > disc claim the JPEG filetype? I think I have at least five.) Another
> > not-so-uncommon case which the design should have taken into account,
> > but didn't because it simply doesn't arise on Linux.
>
> Indeed, this is an issue that is unresolved. If you have any thoughts, I'd
> be most interested...

Ditch SysVars. Use the perfectly serviceable !Boot system instead.
RiscPkg tried to reinvent a lot of wheels because it didn't think the
original ones were Linuxy enough, and in most cases it did a worse job.

SysVars is just one of the reasons I don't think RiscPkg is
realistically salvageable as a system which works for, rather than just
on, RISC OS. I know Alan thinks it can be done, but he also disagrees
that many of the problems I see in the system are in fact problems,
which naturally reduces the scope of the required changes a great deal.
Packages aren't that well established yet. We can still start anew,
learn from our mistakes, and do it properly next time.

--
__<^>__
/ _ _ \ I don't have a problem with God; it's his fan club I can't stand.

( ( |_| ) )

[Matthew Phillips]

In message <9ec2393a...@blueyonder.co.uk>

on 10 Apr 2013 Martin Bazley wrote:

> I can't post much more because I seriously need to finish coursework and
> start revising, and I think the discussion is approaching its conclusion
> anyway. But anyway, here are some responses to a few points raised.

This thread has improved as it has progressed, thank goodness. We have had
threads about packaging every few months and they have usually started out
with aggressive unhelpful criticisms and generalisations like "it's totally
alien to RISC OS", "how could anyone design it like that" and so on. But
when people have got past that we've had some good discussion. Let's hope
next time we don't have to go through the unhelpful stage!

I think Alan has done a great job improving PackMan and providing something
way better than the previous packaging interface. It would be good to see
further developments along the lines people have been discussing, together
with better support in the OS, particularly around stuff like adding to apps,
SysMerge, installing fonts and so on.

I don't think we're ever going to solve the problem of folk moving
applications around very easily. If I set out to design a system where
people could put things where they want, this is what I would consider:

1. In the package manager, have an automatic option, to allow the user to
accept defaults for hundreds of packages if desired, but a way to be
presented with a drag-and-drop icon to install elsewhere if desired.

Problems:
Take the example of Impact, where it has a few helper applications which need
to be seen for some functions to work (e.g. label printing, e-mail merging)
and traditionally they are placed in the same directory so that (a) if the
user navigates there with the Filer they are booted (b) if Impact is added to
Apps and run from there, it at least has a fighting chance of locating and
booting the other apps. Not sure how offering drag-and-drop for !Impact
would cope with setting a default of putting !LabPrint and !ImpEmail
alongside in the same parent directory. Perhaps the parent directory is what
is offered for installation?

2. The package manager remembers where things have been put, so it can update
them automatically. But if it cannot find them, it examines <AppName$Dir> to
see if it can locate the app from that, and checks with the user.

Problems:
a) people sometimes move apps because they are old, but want to keep the old
version somewhere just in case. Obviously this is not very sensible with a
package manager in play.

b) Not all apps will have been booted, so the package manager may not
locate a moved app. Offer to trawl the hard disc?

c) Not all apps set their <AppName$Dir> on !Boot anyway.

d) The user might have recently run an ancient version of the same
application from some obscure location (or even on another machine) so
locating the current managed app via the system variable would be pretty
unreliable in general.

e) The correct system variable would need associating with the package: you
cannot just look through !Boot and !Run to pick out Set Blah$Dir and assume
Blah is the application's name, by any means!


What support could be added to the OS?

Could you have the package manager running all the time, and via some sort of
callback spotting when people move applications about using the Filer? I
don't know whether that would be technically possible.

Alternatively, have some indication in an app directory that it is managed by
the package manager, and alter the Filer so it looks for this and warns the
user if the user decides to move it, or at least informs the package manager
somehow.


On reflection, users already have problems if they move applications. If the
application has been added to Apps or added to the boot or run lists in !Boot
then moving the application directory will break those things anyway. You
can look at this two ways:

a) the package manager is no worse off than key parts of the !Boot system so
there's no need to bother about the problem;

b) the problem is worth fixing, because a fix for the package manager might
benefit those users who hate pacakage managers also.

Again, however, you get the problem of the user moving the old application to
"hide" it and putting a new one in its place. In that use case, the current
system of "look at" and "run on boot" is not broken. RISC OS assumes some
level of understanding, and generally operates on a fairly simple level so
that users *can* actually understand the consequences, and this is one of its
great strengths.


I'me sure there are a lot of flaws with the above thoughts, but it just shows
it's pretty hard doing a good job of package management on RISC OS. You're
never going to please everyone.

I have to say, when we got our Beagleboard two years ago that one of the most
tedious things was setting up a new RISC OS computer for the first time in
eight years. Trying to remember where to get everything from and how we had
set things up, when some applications just didn't work or sort of worked but
had non-functioning dependencies was a hassle, and that's as an "expert"
user. So I really applaud the efforts to get package management going for
all those new users who have installed RISC OS on their Raspberry Pis.

--
Matthew Phillips
Durham

[Alan]

On Wednesday, 10 April 2013 15:04:54 UTC+1, Martin Bazley wrote:
>
> > > At best, all you need is an option to ask the user if they want the
> > > application to be booted and/or run on startup. Ideally, this should
> > > integrate into the existing, defined methods of doing so - see comments
> > > about SysMerge later.
>
> > That sounds like a nice idea. There's one awkward aspect - that booting
> > piles of applications causes lots of random file reads, which tends to
> > thrash disc (and flash) quite a lot and thus be slow - but I'm sure there
> > are ways to address that.
>
> That's the user's problem. If you shovel a load of stuff into your boot
> sequence, you will have a slow boot sequence! This is one reason - the
> other being the filetype claim conflicts business - why such things
> should be strictly optional.

I do agree with you that this should be strictly optional. I always thought
of the SetVars and !Sprites thing as a cache to speed up boot and it's
always nice to try to make the users experience better.

I'd also like the package manager to give you a nice graphical way to see
what it's set after the event and allow you to choose which application
claims which filetype at startup.

>
>
> The most the manager should do is recommend that certain packages are
> automatically booted, in the case of command line programs which aren't
> much use otherwise. But this isn't really appropriate for most normal
> applications.

The filetype and sprites for filetypes claimed is appropriate for most
viewer/editors, but it does need to be configurable for the cases when
there are a clash. Trying to do this by making sure you run the programs
in the right order or edit the applications !Boot files doesn't seem
very friendly to me.

>
> Ooh, Add to Apps - something else the package manager could offer as an
> option. This is all based on existing technology, by the way - Acorn
> seemed to have intended the interface used by Configure to be used by
> third party installers such as, say, a package manager, but it all got
> rather lost after Phoebe was cancelled.

This isn't something I had thought of before and does seem like a
good idea.

>
> I'm a bit out of my depth here, because I don't know how PackMan
> implements the moving of packages internally. If a package has more
> than one application in it, can you move the two to different locations?
> Can you move things other than applications? Does it work at the
> application level, or at the file level? Graham once told me that
> LibPkg works at the file level and doesn't really understand
> applications, but does this mean you'd have to define every single item
> beneath a directory as moved?
>

LibPkg has a Paths database that is uses to define a translation from
the virtual file location in the Package to a physical location on disc.
It works by working back from the full path name and up the directories
until it gets a hit and replace the appropriate part of the file name
to create the real file name. This means you can have paths for individual
files if you want, but only need to do their containing directory.

>
> As it currently stands, however, downloading individual files - for
> which you usually care even more than for applications exactly where
> they are installed - is either tedious or impossible.

It is possible, but probably tedious and difficult to move them.

> I know Alan thinks it can be done, but he also disagrees
> that many of the problems I see in the system are in fact problems,
> which naturally reduces the scope of the required changes a great deal.
>

Yes I still think it can be done. You are right I didn't agree with you
that some things that you said were problems, are in fact problems. I
did think I was moving towards addressing some of these even if I didn't
agree with them, usually after careful consideration and seeing the
reaction of others to your suggestions. But I tend to have little time
and go in small steps. There are a lot of your suggestions that I agree
with as well, it will just take time to do something about them.

> Packages aren't that well established yet. We can still start anew,
> learn from our mistakes, and do it properly next time.
>

Please do. I want Packaging on RISC OS and obviously am less fussy
about some aspects of it than you are.

I just thought that the same conclusion and much discussion happened
about a new system last year and nothing came of it, so I'm going
to take the same attitude I did after last year of gradually improving
PackMan while I'm waiting.

You obviously are busy now and have run out of time to spend it
replying to more newsgroup postings, but in an effort to move forward
rather than worrying about the past, is there a minimum set of
things you would need in PackMan to start using it or is it really
a lost cause to you.

The most obvious is drag-and-drop of the location to install
packages. Before I tackle this I will need input on how the
front-end (and possibly back-end) should do this. If this
is useful I'll start another thread to discuss the issue.

There are some things (like categories) that I don't want
to sort out on my own or be responsible for, but that doesn't
mean if someone else can sort it out I won't enable it
in PackMan.

Regards,
Alan

[John Rickman Iyonix]

Martin Bazley wrote:
>> Packages aren't that well established yet. We can still start anew,
>> learn from our mistakes, and do it properly next time.

Alan wrote

> Please do. I want Packaging on RISC OS and obviously am less fussy
> about some aspects of it than you are.

I don't know if I count as fussy or not. I organize my RISC OS
applications alphabetically into 26 directories, so Artworks and
Avalanche go in A1, StrongED goes in S1, Zap int Z1 etc.

Whether this is the best way to organize a system does not matter. I
have done it for a long time and have no desire to change a system
that works well for me.

If the RISC OS packaging system can accommodate my way of organizing
applications and look after the Boot stuff, I will gladly use it.
If it won't allow me to keep the apps where I want at the moment but
is working towards this being possible, then again I will use it.

When I discussed this with Graham Shaw some time ago it did not look
likely to be possible with his package manager.

But it is good that peace has broken out in the package wars, and I
commend Alan for his patience, and Martin for his persistence.

John

--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Infinity is Sad. God is infinite. God is very sad.

[Stuart]

In article <8d81cd3a5...@rickman.argonet.co.uk>,

John Rickman Iyonix <ric...@argonet.co.uk> wrote:

> I don't know if I count as fussy or not. I organize my RISC OS
> applications alphabetically into 26 directories, so Artworks and
> Avalanche go in A1, StrongED goes in S1, Zap int Z1 etc.

I, on the other hand, organise by function. Thus, my internet directory
contains !Pluto, !PopStar, !NewsHound, !BookMaker, browsers (In separate
sub directories) and various other tools associated with network and
internet stuff. A sound directory contains things like Rhapsody3 and 4,
!AMPlayer, !DigitalCD, !PlayMP3 and so on.

It works for me. :-)

--
Stuart Winsor

Midlands RISC OS Show 13th July 2013

[Martin Bazley]

The following bytes were arranged on 11 Apr 2013 by Alan :

> You obviously are busy now and have run out of time to spend it
> replying to more newsgroup postings, but in an effort to move forward
> rather than worrying about the past, is there a minimum set of
> things you would need in PackMan to start using it or is it really
> a lost cause to you.

I refer the reader once again back to my ROOL post, but the really
important stuff is:

* Remove all remaining assumptions about layout of user's hard disc.
* Get rid of the shadow boot sequence, including SysVars and Sprites,
and work towards properly integrating with the real boot sequence.
* 'Expert mode'.

The first two are necessary to make LibPkg/PackMan into a RISC OS
package manager, rather than a Linux package manager ported to RISC OS.
The last one is necessary for me to start using it, not through any
particular bad experience with LibPkg, but because RPMs try to boss you
around without providing overrides and this has caused me a lot of pain.

Actually, the last bullet point in my ROOL post deserves repeating:

* Never get in the way.

--
__<^>__ "Start off every day with a smile and get it over with."
/ _ _ \ - W.C. Fields

[Alan]

On Friday, 12 April 2013 12:35:37 UTC+1, Martin Bazley wrote:
> The following bytes were arranged on 11 Apr 2013 by Alan :
>
>
> > You obviously are busy now and have run out of time to spend it
> > replying to more newsgroup postings, but in an effort to move forward
> > rather than worrying about the past, is there a minimum set of
> > things you would need in PackMan to start using it or is it really
> > a lost cause to you.
>
> I refer the reader once again back to my ROOL post, but the really
> important stuff is:

I was after the important stuff, thanks. Time constraints means things need
to be tackled a little at a time.

>
> * Remove all remaining assumptions about layout of user's hard disc.

I've just started a new post to get feedback on how to implement this.

>
> * Get rid of the shadow boot sequence, including SysVars and Sprites,
> and work towards properly integrating with the real boot sequence.

I'm not convinced of this one yet, but agree more control is needed.

Would a simple override for all packages for the SysVars and
Sprites be enough to be going on with for now or is it an all
or nothing deal?

I believe PackMan should be better at checking existing System modules
and believe the conflict manager and upgrades should be much smarter
than they are now. I just can't see me getting to this in the short
term.

> * 'Expert mode'.
>
> The first two are necessary to make LibPkg/PackMan into a RISC OS
> package manager, rather than a Linux package manager ported to RISC OS.

You know I don't agree that this is currently the case, but there's
no point in trying to argue it any more. Hopefully I can get PackMan
to the stage where you believe it is a RISC OS package manager.

> The last one is necessary for me to start using it, not through any
> particular bad experience with LibPkg, but because RPMs try to boss you
> around without providing overrides and this has caused me a lot of pain.
>

Fair enough, I can't see Expert mode happening in the short term either.

It looks like I'm not going to get anything that you could switch to in
the short term and though I have good intentions of addressing the second
two points, I can't promise it will happen for a while or that you
will be 100% happy with the results.

Oh, well, if the new thread I've started goes well, at least next year
when this argument starts up again there will be one less thing to
complain about.

Or maybe you will have written and finished your package manager
and the discussion will be on how I can best help people move
their applications from PackMan to whatever it is.

Regards,
Alan

[John Rickman Iyonix]

Stuart wrote

I started saving apps by category but eventually found it too
confusing. I ended up with lots of categories eg

audio, development, document, dtp, edit, file management, font, games,
graphics, mapping, net, numbers, print, system, time, usb, video, web,
words, zip pgms.

As the number of apps grew the decisions got harder as to which
category, or categories! a new app belonged in. It got so I couldn't
find where I'd put apps that were not used much. So I changed to the
"save by initial letter" and have lived happily ever after.

[John Williams (News)]

In article <bae8413b5...@rickman.argonet.co.uk>,

John Rickman Iyonix <ric...@argonet.co.uk> wrote:

> I started saving apps by category but eventually found it too

> confusing. I ended up with lots of categories eg ...

Which only confirms that we all have our own individual ways of organising
our lives and our hard discs - which PackMan needs to take account of!

John

--
John Williams, now back in the UK - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

[Stuart]

In article <533b52c8...@tiscali.co.uk>,

John Williams (News) <UCE...@tiscali.co.uk> wrote:
> In article <bae8413b5...@rickman.argonet.co.uk>,
> John Rickman Iyonix <ric...@argonet.co.uk> wrote:

> > I started saving apps by category but eventually found it too
> > confusing. I ended up with lots of categories eg ...

> Which only confirms that we all have our own individual ways of
> organising our lives and our hard discs - which PackMan needs to take
> account of!

Indeed.

[Harriet Bazley]

On 11 Apr 2013 as I do recall,
Matthew Phillips wrote:

[snip]

> I don't think we're ever going to solve the problem of folk moving
> applications around very easily. If I set out to design a system where
> people could put things where they want, this is what I would consider:
>

Thinking about package management from the RISC OS end... perhaps the
most appropriate approach would be for the *user* to tell the package
manager what app he wants to be checked/updated by simply dragging it to
the package manager's iconbar icon? (Or a drop-box icon in a window, or
something.)

This equates to 'please tell me if there are any updates online or
whether any of the dependent packages have been updated, etc'....

--
Harriet Bazley == Loyaulte me lie ==

Even a cabbage may look at a king.

[John Rickman Iyonix]

Harriet Bazley wrote

> Thinking about package management from the RISC OS end... perhaps the
> most appropriate approach would be for the *user* to tell the package
> manager what app he wants to be checked/updated by simply dragging it to
> the package manager's iconbar icon? (Or a drop-box icon in a window, or
> something.)

> This equates to 'please tell me if there are any updates online or
> whether any of the dependent packages have been updated, etc'....

I think this idea has good potential. You could to do a one-off drag
and drop of all applications onto the package manager. This would
"register" them, so to speak . The manager would record the locations
and would know where updated applications were to be stored.
If you wanted to change the location of an app you could move it to
its new home then drop it onto the manager again to update the
registration.

New applications could be put to a default location by the package
manager, then moved by the user and dropped back on the manager to
register their proper home.

For existing systems this would be fairly painless. For new, empty
systems it would mean more work but with no urgency about completing
it, as the apps can be left in the default locations initially.

John

--
John Rickman - http://rickman.orpheusweb.co.uk/lynx

"Poetry is a MUG's game" - TS Eliot

[Bryan Hogan]

This Monday�s ROUGOL meeting will be a demo and discussion about
package management.

http://www.rougol.jellybaby.net/meetings/

Entry is free, so everyone is welcome to come along and give their
opinions!

Bryan.

--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/

[David Holden]

On 12-Apr-2013, John Rickman Iyonix <ric...@argonet.co.uk> wrote:

> Harriet Bazley wrote
>
> > Thinking about package management from the RISC OS end... perhaps
> > the most appropriate approach would be for the *user* to tell the
> > package manager what app he wants to be checked/updated by
> > simply dragging it to the package manager's iconbar icon? (Or a
> > drop-box icon in a window, or something.)
>
> > This equates to 'please tell me if there are any updates online or
> > whether any of the dependent packages have been updated, etc'....
>
> I think this idea has good potential. You could to do a one-off drag
> and drop of all applications onto the package manager. This would
> "register" them, so to speak . The manager would record the
> locations and would know where updated applications were to be
> stored. If you wanted to change the location of an app you could

> move it toits new home then drop it onto the manager again to

> update the registration.
>
> New applications could be put to a default location by the package
> manager, then moved by the user and dropped back on the manager to
> register their proper home.
>
> For existing systems this would be fairly painless. For new, empty
> systems it would mean more work but with no urgency about completing
> it, as the apps can be left in the default locations initially.

This won't work. It's absolutely sensible, completely logical and
entirely in accord with the way RISC OS does things..It would require
someone to bin all their preconceived ideas about how these programs
are 'supposed' to work and start from scratch rather than try to port
something from Linux. So none of the people who've already written
such programs would be able to do it because they'd first have to
admit that everything they've done so far has been a complete waste of
time (except that it's FINALLY produced a blueprint for a sensible
approach) and should be scrapped.

In fact, it wouldn't even be a 'package manager' in the usual sense.
It would be a RISC OS application updater.

Never happen :-((

--
David Holden - APDL - www.apdl.co.uk

[druck]

On 11/04/2013 17:58, John Rickman Iyonix wrote:
> I don't know if I count as fussy or not. I organize my RISC OS
> applications alphabetically into 26 directories

DFS is alive and well!

---druck

[John Rickman Iyonix]

druck wrote

Actually I have 27 directories -
(in a dir APPZ so named as to keep it distinct from the RISC OS Apps
directory)
The directory names are A1 to Z1, and one for apps that start with a
number - directory name: 0_9

This contains Steve Revill's !7Backup and Robin Edwards' !1st
statistical package. If numerically named apps became popular I might
end up with 36 directories in APPZ

--
John Rickman - http://rickman.orpheusweb.co.uk/lynx

it transcends plausibility, it's a fact. david mercer

[Bryn Evans]

In a mad moment - John Rickman Iyonix mumbled :

Till now I have never fancied using a Package Manager - BUT -

At last, a sensible RiscOs style suggestion that I would jump at
straight away.
Please, someone, write it, to follow the details in these two posts.



--
|)����[
|)ryn [vans mail to - Bryn...@bryork.freeuk.com

[Theo Markettos]

John Rickman Iyonix <ric...@argonet.co.uk> wrote:

> I think this idea has good potential. You could to do a one-off drag
> and drop of all applications onto the package manager. This would
> "register" them, so to speak . The manager would record the locations
> and would know where updated applications were to be stored.
> If you wanted to change the location of an app you could move it to
> its new home then drop it onto the manager again to update the
> registration.

That's an interesting idea. That could almost be implemented as-is: the
Paths file indicates where Apps.Category.!Thingy should be installed, so
adding a mapping in there to a new place would automatically mean that
!Thingy would be installed in that new place. As an installation wouldn't
know what version of !Thingy had been installed before, it would offer to
back up the old files before replacing them.

The only stumbling block to implementing a utility to rewrite the Paths file
like this right now is we'd need to know the Category bit in advance,
without having seen an appropriate package. However if we were to move to a
package format where there's no Apps.Category bit and all the apps are at
the top level, then it would work straight off. In that case there would
have to be another way to indicate the 'default' installation location if
there was no further information, but that could be done.

Theo

[David Holden]

On 13-Apr-2013, Theo Markettos <theom...@chiark.greenend.org.uk>
wrote:

> The only stumbling block to implementing a utility to rewrite the
> Paths file like this right now is we'd need to know the Category
> bit in advance, without having seen an appropriate package.
> However if we were to move to a package format where there's
> no Apps.Category bit and all the apps are at the top level, then
> it would work straight off. In that case there would have to be
> another way to indicate the 'default' installation location if
> there was no further information, but that could be done.

No, no NO. You've missed the point. This is not Linux or Windows, this
is RISC OS. There is no 'default location', no place where programs
are 'normally' placed (except common resources, and that's a different
problem). Every time a new application is installed using a package
manager it ASKS where to install it in the usual RISC OS way, by
opening a 'Save As' window for the user to drag it to where he/she
wants it. The manager then remembers that location for the purpose of
checking for updates. It's trivial, but it requires the discarding of
all the preconceived ideas of how package managers work on other
platforms. In fact, it would be much better written by someone who had
no experience of them on other platforms so they'd start with a clean
sheet.

No 'defaults' no 'categories', just does what it's told.

[Theo Markettos]

David Holden <spa...@apdl.co.uk> wrote:
>
> No, no NO. You've missed the point. This is not Linux or Windows, this
> is RISC OS. There is no 'default location', no place where programs
> are 'normally' placed (except common resources, and that's a different
> problem). Every time a new application is installed using a package
> manager it ASKS where to install it in the usual RISC OS way, by
> opening a 'Save As' window for the user to drag it to where he/she
> wants it.

And how do you:
1. Install three hundred packages in one go, without causing the user to die
of boredom after the first dozen?
2. Automatically assemble a disc image like the Raspberry Pi SD card -
things have to go /somewhere/ ?

If you have ways to do those without the need for a 'just put it in the
default place' mode (and optionally move it afterwards), I'd be most
interested...

That's not to say such a method is required in everyday use, of course. If
you accept that a 'just do it' mode is necessary, categories are an attempt
to impose some kind of order on the result (rather than, say, putting 300
apps in $.Apps), but they aren't the only way (other answers welcome).

Theo

[Vince M Hudd]

"David Holden" <spa...@apdl.co.uk> wrote:
> On 13-Apr-2013, Theo Markettos <theom...@chiark.greenend.org.uk> wrote:

> > However if we were to move to a package format where there's no
> > Apps.Category bit and all the apps are at the top level, then it would
> > work straight off. In that case there would have to be another way to
> > indicate the 'default' installation location if there was no further
> > information, but that could be done.
>
> No, no NO.

[...]

> Every time a new application is installed using a package manager it ASKS
> where to install it in the usual RISC OS way, by opening a 'Save As'
> window for the user to drag it to where he/she wants it.

That's all very well - but even I (as someone who has always objected to the
forced install locations of the RISC OS Packaging Project) can see that
default locations *are* necessary.

A "Save dialogue for every application" does not scale well. As I said a few
days ago on the ROOL forums:

----8<----
the idea of a simple save box for the application that’s just been
downloaded by the package manager only really works for a case where the
user is downloading and installing one thing at a time. A package manager
should allow for multiple downloads and installations – and if that resulted
in a stream of save dialogues, it would probably become annoying.

And I can well imagine it causing more problems: The first package has been
successfully downloaded, and the [persistent] save dialogue opened. It’s a
game, so you open the folder in which you want to put your games and return
your attention to the save dialogue in order to drag the icon to the
directory. What you don’t notice that while you were navigating to the Games
directory, another package had finished downloading and its save dialogue
opened. This one’s a graphics application – and its this one you’ve just
dragged to [installed in] games, without actually noticing.
----8<----

Complaining that the package managers don't support drag and drop
installation is one thing - but we have to be pragmatic and accept that
there will be situations when the package manager should just get on with it
and use some sensible defaults (aka categories*).

* Or whichever one is listed first if multiple categories per app are
allowed in future.

--
Soft Rock Software: http://www.softrock.co.uk
Vince M Hudd: http://misc.vinceh.com/about-vinceh/
RISCOSitory: http://www.riscository.com

[John Williams (News)]

In article <4cu*z7...@news.chiark.greenend.org.uk>, Theo Markettos

<theom...@chiark.greenend.org.uk> wrote:

> And how do you:

> 1. Install three hundred packages in one go, without
> causing the user to die of boredom after the first dozen?

> 2. Automatically assemble a disc image like the Raspberry Pi SD card -
> things have to go /somewhere/ ?

I think point 2 calls for a script which can and must specify a location.

That might cover point 1 as well if the user can edit the locations in the
script to suit themselves.

But the script interpreter could be /in addition/ to the drag-and-drop mode
of operation for single installs.

A suggested default location could be offered in the save box, but could be
altered by the user if/when required/desired.

Just an idea ...

[Stuart]

In article <4cu*z7...@news.chiark.greenend.org.uk>,
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:

> And how do you: 1. Install three hundred packages in one go, without
> causing the user to die of boredom after the first dozen?

Can't be any worse than installing Windows <g>

I've been a RISC OS user for a long time and I doubt if I've got one
hundred never mind three hundred.

[John Rickman Iyonix]

Theo Markettos wrote

A 'just do it' mode is useful for large scale importation.
But for the people who want to put apps into places of their own
choosing the categories are a nuisance as they scatter the apps and
may create unwanted directories.

If there is an option to have just one single user definable category
where everything is put then that would help.


john

--
John Rickman - http://rickman.orpheusweb.co.uk/lynx

For ye have the poor always with you; but me ye have not always.

[spampling]

In article <asv1db...@mid.individual.net>,

David Holden <spa...@apdl.co.uk> wrote:
> No, no NO. You've missed the point. This is not Linux or Windows, this
> is RISC OS. There is no 'default location', no place where programs
> are 'normally' placed (except common resources, and that's a different
> problem). Every time a new application is installed using a package
> manager it ASKS where to install it in the usual RISC OS way, by
> opening a 'Save As' window for the user to drag it to where he/she
> wants it.

..and if the user does not express a preference it installs them to the
default.

I think that was the bit you missed.

For old lags, drag and drop multiple times is just the way it has always
been[1], for new users even the concept of running an application from
within a zip file is foreign.
They just want to use it and don't care where the system puts it as long as
it works the next time they boot up.

[1] Although even Vince dislikes the multiple save box malarkey.

--

Steve Pampling

[Dave Higton]

In message <4cu*z7...@news.chiark.greenend.org.uk>

Theo Markettos <theom...@chiark.greenend.org.uk> wrote:

>And how do you:
>1. Install three hundred packages in one go, without causing the user to die
>of boredom after the first dozen?

No-one has ever done that in the entire history of RISC OS and its
users.

Dave

[Vince M Hudd]

I've just tried the latest version of PackMan, and unless I've missed
something, no-one would will be able to do that, either.

It looks as though the UI for installing a package is:

+ Click <MENU> over the package
+ Follow the package submenu
+ Click on "Install" on the submenu
+ Click "Install" in the "Install package" window that opens
= The package is downloaded and installed there and then.

I was under the impression a user could select more than one package, and
have them all downloaded and installed in one go, but the closest I can get
to that is to go through the above steps for the next package while the
previous one is downloading and installing.

As it stands, I see no reason why (for those packages for which it is
appropriate) the "Install" button is replaced by a drag and drop interface:
instead of clicking the button, perform a drag to the required location (or
click the "install" button below it to select the 'default' location). When
user ends the drag, the installation commences.

I'm actually quite shocked by this. I could - to some extent - understand
the logic of installing in default locations if the package managers were
written such that an arbitrary number of packages could be selected and
installed en mass - but (PackMan, at least) isn't, and that makes the
insistence on forcing the categories on users as the target locations for
the installed applications even more ludicrous.

I shouldn't be shocked, because I've tried the software before, so I almost
certainly realised before that it was limited in this way - and clearly
forgot just how bad they were.

IMO, the UI should allow installation there and then (i.e. as now but with a
drag and drop interface where appropriate), and the ability to select and
install en mass (for which sensible defaults would be acceptable).

I'd suggest a number of things that would work around this, as well as
improve the UI overall (sorry, Alan - I know you're trying!):

A couple of points about the UI as it is:

Firstly, when I clicked the "Install" menu entry, I was expecting the
installation to happen there and then, rather than open a window. That, to
me, seemed somewhat odd for the reasons given above. Directly related to
this is that there is some overlap between what's in this window, and what's
in the "Info" window for the packages.

Secondly, after establishing the presence of that window, I noted I couldn't
double-click on an application to go straight to that window (or the info
window) - OTOH, that makes sense: Which window would be the most appropriate
to open?

What I think might work as an alternative - again for those packages for
which it is appropriate - is:

The menu for the package contains:

Info
Install to... [Move to...]
Install now
Open folder
Apps
Uninstall

Info opens the package's info window. There is no longer a separate install
package window which doubles up on its contents. The info window can contain
a draggable icon, along with a save path (which defaults to the category
based default) and a button to "install"

Clicking on "Install" in that window without a drag and drop installs the
application to its (category based) default location.

Dragging the icon to a suitable location causes the window to be closed and
the application to be downloaded and installed in that location.

Clicking on the "Install To..." menu entry should open a save dialogue, from
which a drag and drop installation can be carried out. I.e. it does the same
as the icon in the package info window, but with a standard save dialogue.
This might seem like a duplication, but it's more 'obvious' than going into
"info" to "install" - the duplication, really, is a time saver. If the user
has looked at the package info, saving from there instead of going back to
the menu is a nicety.

For packages already installed, the menu entry becomes "Move to..." rather
than "Install to..." and (obviously) it opens a save dialogue which results
in the application being moved to wherever the drag leads.

Clicking on "Install Now" will simply cause the package to be installed in
its (category based) default location.

"Open folder" opens the containing folder for installed package.

"Apps" opens the "Apps" window as now. I'm sure that's useful for something
- though I didn't really look at it. (I gather from another post that's
where the "Move" option is at the moment).

"Uninstall" is the same as "Remove" now. The only reason I've called it
"uninstall" is because that's consistent with "install".

With that (or a, if not as above) revised menu, and the removal of the
unnecessary duplication between the current info/install windows, double
clicking on an app in the list of packages should open the [new] info
window. (A double-click with ADJUST could perhaps open the Apps window?)

Another thing I tried to do - mainly because I frequently forget how weak
RISC OS is in this area - was, once a package was highlighted, use the
cursor keys to go up and down the list. Why not make that possible, with a
press of <space> opening the [new] Info window? (And in that <Return>
installs now and closes the window, while <Escape> just closes it).

Another thing that springs to mind is rather than opening the progress
window for the downloading and installing (which might lead the user to
thinking that they should wait for it to finish before moving on), why not
have a status line at the bottom of the main window which says provides some
information on how many packages are being downloaded/installed?

Also: As I've said before, more than once. If a user moves an app via the
filer, when PackMan tries to update it and finds it missing, pop up a
dialogue allowing the user to drag the moved app onto it in order to
register its new location (with an option to defer this until a later time)
- and as someone else suggested, if the user drags an app onto PackMan, it
should check the app against those installed; if it's one, update the
location stored for it.

I had something else in mind a few paragraphs ago, which I thought I'd make
the final suggestion - but I've now forgotten what it was. Ho hum.

[Steve Fryatt]

On 14 Apr, Dave Higton wrote in message
<177e6b3c5...@my.inbox.com>:

True, but then neither has anyone had to install new ROM images by
drag-and-drop into SDFS until recently...

;-)

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

[Steve Fryatt]

On 14 Apr, Stuart wrote in message
<533c444e...@argonet.co.uk>:

> In article <4cu*z7...@news.chiark.greenend.org.uk>,
> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>
> > And how do you: 1. Install three hundred packages in one go, without
> > causing the user to die of boredom after the first dozen?
>
> Can't be any worse than installing Windows <g>
>
> I've been a RISC OS user for a long time and I doubt if I've got one
> hundred never mind three hundred.

Remember that packages aren't just applications: they can also be bits of
!Boot and -- on systems like the Raspberry Pi -- even things like the ROM
image itself.

[spampling]

In article <mpro.ml9ppb0i...@stevefryatt.org.uk>,

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> True, but then neither has anyone had to install new ROM images by
> drag-and-drop into SDFS until recently...

I suspect if the Select scheme had been offering updates as regularly as
the various incremental releases there would have been considerably fewer
disgruntled subscribers.
Shame about Select, nice idea, naff delivery.

Interesting to note that Justin blames himself for that when my perception
was more leaning toward bad marketing/management. Still, water under the
bridge and all that.

--

Steve Pampling

[Alan]

On Saturday, 13 April 2013 07:10:41 UTC+1, David Holden wrote:
>
> > Harriet Bazley wrote
>
[snip Harriet's idea]

>
> This won't work. It's absolutely sensible, completely logical and
> entirely in accord with the way RISC OS does things..

I'm not commenting on Harriet's idea here one way or another so
please don't think anything that follows has anything do do
with it's merits.

> It would require
> someone to bin all their preconceived ideas about how these programs
> are 'supposed' to work and start from scratch rather than try to port
> something from Linux. So none of the people who've already written
> such programs would be able to do it because they'd first have to
> admit that everything they've done so far has been a complete waste of
> time (except that it's FINALLY produced a blueprint for a sensible
> approach) and should be scrapped.

It's attitudes like these that are completely counter-productive. My
main irritation about comments on the newsgroups is about people who
won't look at new ideas with an open-mind and at least try to understand
why someone would come up with them, but instead dismiss them by trying
to use the word "Linux" as some kind of bogey man. I know it may
be a strange idea to you, but why not actually try to use something
and offer helpful criticism on what's wrong with it and why you don't
like it rather than saying just "it's not RISC OS". I don't mind people
saying it should be improved as it's not working the way they
expect a RISC OS application to work, and I also have no complaints
about saying this it what is done on "Linux" or some other system
and what it's problems are.

I saw packaging on Cygwin and Debian and thought the idea of
finding and installing packages a good one and I think even
Martin uses Linux more than I do (not difficult as my main
use of it is for runnning the GCCSDK cross-compiler for
RISC OS programs). I'm also technically competent enough to
set up and use Linux if I wanted a Linux system, but I want
to use RISC OS, not a clone of Linux. So when you are
next about to launch into an attack based on "Linux" just
try to think the person who is developing PackMan is a
RISC OS user who want's something for his RISC OS machines.

I didn't write the Packaging system, I found a Packaging
system for RISC OS, I evaluated what it did for me and
found it useful on RISC OS to install RISC OS applications
and their dependencies.

Just one more point on your last statement, I've always maintained
I want a Packaging system for RISC OS and it doesn't have to
be the one I've been working on. I even took part in the discussions
over a year ago on the newsgroups about a new Packaging system, does
this really sound to you like some one who is hanging on to
something just because he's been involved in it.

> In fact, it wouldn't even be a 'package manager' in the usual sense.
> It would be a RISC OS application updater.
>
> Never happen :-((

A RISC OS application updater may not, but there is already a Package
Manager that's being maintained for RISC OS, and there's a slight
chance that with a bit of co-operation there could be a Package
Manager that a lot more users will be happy with.

Alan

[Alan]

On Sunday, 14 April 2013 22:45:44 UTC+1, Vince M Hudd wrote:
> Dave Higton <da...@davehigton.me.uk> wrote:
>
> > In message <4cu*z7...@news.chiark.greenend.org.uk>
>
> > Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
>
> > > And how do you: 1. Install three hundred packages in one go, without
> > > causing the user to die of boredom after the first dozen?
>
> > No-one has ever done that in the entire history of RISC OS and its users.
>
> I've just tried the latest version of PackMan, and unless I've missed
> something, no-one would will be able to do that, either.
>
> It looks as though the UI for installing a package is:
> + Click <MENU> over the package
> + Follow the package submenu
> + Click on "Install" on the submenu
> + Click "Install" in the "Install package" window that opens
> = The package is downloaded and installed there and then.
>
> I was under the impression a user could select more than one package, and
> have them all downloaded and installed in one go, but the closest I can get
> to that is to go through the above steps for the next package while the
> previous one is downloading and installing.
>

You haven't missed anything, it's missing from the PackMan UI at
the moment. It's one of the things that !RiscPkg does that hasn't
got into PackMan yet.

You can shorten the steps, just to select the package and then
click the install button on the toolbar.

>
>
> As it stands, I see no reason why (for those packages for which it is
> appropriate) the "Install" button is replaced by a drag and drop interface:
> instead of clicking the button, perform a drag to the required location (or
> click the "install" button below it to select the 'default' location). When
> user ends the drag, the installation commences.
>

Yes, I wondered about this as well. I was thinking more of the Install
button/menu options being equivalent of the Save As dialogue and I
wanted to know exactly what it was doing, including a full list of
what it going to install before anything happens. The other things
is how do you make it clear to someone that dragging won't make
a difference for some packages as they have to go in a fixed place.

>
>
> I'm actually quite shocked by this. I could - to some extent - understand
> the logic of installing in default locations if the package managers were
> written such that an arbitrary number of packages could be selected and
> installed en mass - but (PackMan, at least) isn't, and that makes the
> insistence on forcing the categories on users as the target locations for
> the installed applications even more ludicrous.

The thing about PackMan is I wanted to make it easier and clearer to
install single packages straight away. There is every intention of
allowing for multiple package installs at some point in the future
at which point the default install location makes more sense.

>
> I shouldn't be shocked, because I've tried the software before, so I almost
> certainly realised before that it was limited in this way - and clearly
> forgot just how bad they were.
>
> IMO, the UI should allow installation there and then (i.e. as now but with a
> drag and drop interface where appropriate), and the ability to select and
> install en mass (for which sensible defaults would be acceptable).

This is the problem, different opinions how things should work. I always
want to be told what's going to happen and have to make a positive selection
to start download and installation. I'm always open to suggestion on
better ways of doing it. I've started another thread on specifying the
location PackMan, please feel free to contribute there on this particular
point.

>
>
> I'd suggest a number of things that would work around this, as well as
> improve the UI overall (sorry, Alan - I know you're trying!):

Suggestions have always been welcome. I wrote PackMan because I didn't
like the !RiscPkg UI. As I'm the one doing the work, all it needs is
for me to see that it's better than what's there already and I really
am open minded about the whole area.

>
> A couple of points about the UI as it is:
>
> Firstly, when I clicked the "Install" menu entry, I was expecting the
> installation to happen there and then, rather than open a window. That, to
> me, seemed somewhat odd for the reasons given above. Directly related to
> this is that there is some overlap between what's in this window, and what's
> in the "Info" window for the packages.

This is where it would be nice to get opinions from several people. I
want some sort of confirmation dialogue box to tell me what it's going
to do before it does it. My initial thoughts for changing the location
was it was like a SaveAs box, but I started another thread because
I'm not sure how well that works for all packages.

The Install dialogue is just giving you a summary of what you are
going to install, whereas the Info window is to show you all the
details. Maybe I don't need to put so much on the Install window.

>
> Secondly, after establishing the presence of that window, I noted I couldn't
> double-click on an application to go straight to that window (or the info
> window) - OTOH, that makes sense: Which window would be the most appropriate
> to open?

Yes, double-click should do something. The most frequent suggestion has
been that is shows the "Info" window. I just can't make up my mind what
double-click should do. Though when independent people come up with the
same suggestion it make me lean towards that.

>
> What I think might work as an alternative - again for those packages for
> which it is appropriate - is:
>
> The menu for the package contains:
>
> Info
> Install to... [Move to...]
> Install now
> Open folder
>
> Apps
> Uninstall
>
> Info opens the package's info window. There is no longer a separate install
> package window which doubles up on its contents. The info window can contain
> a draggable icon, along with a save path (which defaults to the category
> based default) and a button to "install"

Interesting suggestion. I always though the window with the Information seemed
to big and preferred a cut down version for install. What happens when the
dependencies need install locations set as well?

>
> Clicking on "Install" in that window without a drag and drop installs the
> application to its (category based) default location.
>
> Dragging the icon to a suitable location causes the window to be closed and
> the application to be downloaded and installed in that location.
>

It's the multiple locations I'm having difficulty with. If you don't
mind please switch to the other thread to continue this discussion so
it's easier for me to pull out.

>
>
> Clicking on the "Install To..." menu entry should open a save dialogue, from
> which a drag and drop installation can be carried out. I.e. it does the same
> as the icon in the package info window, but with a standard save dialogue.
> This might seem like a duplication, but it's more 'obvious' than going into
> "info" to "install" - the duplication, really, is a time saver. If the user
> has looked at the package info, saving from there instead of going back to
> the menu is a nicety.

I like niceties. Duplication to make life easier is OK by me.

>
>
> For packages already installed, the menu entry becomes "Move to..." rather
> than "Install to..." and (obviously) it opens a save dialogue which results
> in the application being moved to wherever the drag leads.
>
> Clicking on "Install Now" will simply cause the package to be installed in
> its (category based) default location.
>
> "Open folder" opens the containing folder for installed package.
>
> "Apps" opens the "Apps" window as now. I'm sure that's useful for something
> - though I didn't really look at it. (I gather from another post that's
> where the "Move" option is at the moment).
>
> "Uninstall" is the same as "Remove" now. The only reason I've called it
> "uninstall" is because that's consistent with "install".
>

Do you need a separate option or should "Install" change to "Uninstall"
where appropriate?

>
> With that (or a, if not as above) revised menu, and the removal of the
> unnecessary duplication between the current info/install windows, double
> clicking on an app in the list of packages should open the [new] info
> window. (A double-click with ADJUST could perhaps open the Apps window?)
>

These are all good suggestions, has any one else opinions on them?

>
> Another thing I tried to do - mainly because I frequently forget how weak
> RISC OS is in this area - was, once a package was highlighted, use the
> cursor keys to go up and down the list. Why not make that possible, with a
> press of <space> opening the [new] Info window? (And in that <Return>
> installs now and closes the window, while <Escape> just closes it).

I agree with this, it's because RISC OS is generally so weak in this area
that I haven't given it any priority.

>
>
> Another thing that springs to mind is rather than opening the progress
> window for the downloading and installing (which might lead the user to
> thinking that they should wait for it to finish before moving on), why not
> have a status line at the bottom of the main window which says provides some
> information on how many packages are being downloaded/installed?
>

Unfortunately they do have to wait for it to finish before they can
install something else. It also makes it easier to cancel and install
(or it would if it worked). It does at least multi-task so you can
find your next package to install while you are waiting. I kind of like
the idea of a separate window rather than trying to shove everything
into the status bar, but I'll think about this one some more.

>
>
> Also: As I've said before, more than once. If a user moves an app via the
> filer, when PackMan tries to update it and finds it missing, pop up a
> dialogue allowing the user to drag the moved app onto it in order to
> register its new location (with an option to defer this until a later time)
> - and as someone else suggested, if the user drags an app onto PackMan, it
> should check the app against those installed; if it's one, update the
> location stored for it.

These are both good suggestions. The problem is time. I don't have that
much of it, so I have been leaving this whole area as something to
improve at a later date.

>
> I had something else in mind a few paragraphs ago, which I thought I'd make
> the final suggestion - but I've now forgotten what it was. Ho hum.
>

I'm sure it will come back to you.

Thanks for the suggestions. I like the UI I created for PackMan, but
it may be it was just because I didn't think of anything better, so
I need to think about your suggestions a lot more. As I've said I'm
currently trying to figure out the UI for the whole install to a
different location thing, so ideas are especially welcome in that area
at the moment.

Regards,
Alan

[Theo Markettos]

...because it's so tedious to do by hand. But if it's easy, why not? Disc
space is cheap, and RISC OS applications are hardly large. If it's easy to
find an application on your disc (ie if they aren't all dumped in together)
and they're kept up to date, why not install applications just in case they
come in handy? For example, there must be dozens of converters between
different file formats - why not have them all to hand in case you need
one?

That's not to mention that a package may be less than a whole application -
for example, a module, a library, a plugin, a document or two.

Theo

[Chris Evans]

In article <bae8413b5...@rickman.argonet.co.uk>, John Rickman Iyonix

<URL:mailto:ric...@argonet.co.uk> wrote:
> Stuart wrote
>
> > In article <8d81cd3a5...@rickman.argonet.co.uk>,

> > John Rickman Iyonix <ric...@argonet.co.uk> wrote:
>

> >> I don't know if I count as fussy or not. I organize my RISC OS

> >> applications alphabetically into 26 directories, so Artworks and
> >> Avalanche go in A1, StrongED goes in S1, Zap int Z1 etc.
>
> > I, on the other hand, organise by function. Thus, my internet directory
> > contains !Pluto, !PopStar, !NewsHound, !BookMaker, browsers (In separate
> > sub directories) and various other tools associated with network and
> > internet stuff. A sound directory contains things like Rhapsody3 and 4,
> > !AMPlayer, !DigitalCD, !PlayMP3 and so on.
>
> > It works for me. :-)

>
> I started saving apps by category but eventually found it too
> confusing. I ended up with lots of categories eg
>

> audio, development, document, dtp, edit, file management, font, games,
> graphics, mapping, net, numbers, print, system, time, usb, video, web,
> words, zip pgms.
>
> As the number of apps grew the decisions got harder as to which
> category, or categories! a new app belonged in. It got so I couldn't
> find where I'd put apps that were not used much. So I changed to the
> "save by initial letter" and have lived happily ever after.

How do you find applications that you rarely use and can't remember the name
of?

Using a dozen or so many categories and then sub categories/ sub sub and so
on works for me.

$.Utilities.FilingSystems.Disk-File-Utils.DriveDataOverwriting.DrucksDiscWipe


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!