Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PackMan setting the install location at install time
20 views
Skip to first unread message
Alan
Apr 12, 2013, 8:33:16 AM4/12/13
to
I'm hoping to get some feedback on how I would implement setting the install location for an application at install time rather than installing it to a fixed location and leaving it there or moving it to another location.
There are two areas to this.
1) The front end, you don't need to be technical to help me figure this out and this is the main part I need help with.
2) The back end. I have a proposal for what I'm thinking of doing for this, but welcome constructive criticism on this.
Of course at the end of the discussion, it would be good to know if the results will suit (most) of the people who require this functionality.
Each package can contain 0 or more items that should be allowed to set their location. e.g. Modules for !System and other such resources have only on place to go, but normal applications should be allowed to have there locations changed.
Each package also can contain dependencies which may need to be able to set their location. There are packages that are installed into one of their dependencies, so if the dependencies isn't already there, it needs to be given the position to install to first.
One of the most important user requirements is that locations can be set by drag-and-drop.
PackMan shows a list of the packages, allows you to choose one and use a button or menu option to install it. My aim is to keep this part the same.
After that, an Install dialogue is shown which gives details of the package to be installed and any dependencies it will also install. It is possible for packages to be removed to be displayed as well.
Currently you then click on Install and off it goes and downloads everything it needs and puts them on the location of your disc specified in the Paths table.
All packages come with a default path and I would like to retain that so you can do a quick install in just the same way as you do now if you are happy with where they will be put.
I'd like opinions on what the new dialogue should look like and how it should work. My initial thoughts are to list each package with it's path and if it can be modified place a draggable icon by it, but any ideas are welcome.
The design needs to take into account that as well as the most common case where there will only be one thing to drag, there may be nothing to drag or several items. I'd like to use a single dialogue for all cases if possible so there is a consistent look to the operation.
Maybe the functionality should vary a little in each case. e.g. Should the most common case of one thing to drag automatically start the install after the drag is completed? or would this cause confusion with the other cases.
Although not essential for the initial release of this it would be nice if anyone could think of a way to make the recommendations and suggestions from the package be a little more prominent and able to be added to the install from this dialogue.
PackMan's user interface doesn't support choosing multiple applications to install at once, but it is something that may come up in future, so please be aware of it.
I'm also considering adding options for more control of other aspects of the install and though I'd rather just stick to sorting out the install location now, it's worth thinking about how the design might be able to add additional options on a package by package basis in future.
I believe the back-end will need updating to make this work as smoothly as possible and am intending to add a new field to the control record that specifies which parts of the package are draggable, but any other suggestions are welcome.
The main advantage I see for this extra field are that as it's in the control record it means the paths can all be set even before anything is downloaded so once you click install all you need to look out for is it to finish.
It also simplifies the coding as there doesn't need to be any heuristics to try to figure out what should be draggable and what shouldn't. It will also mean that the apps window will be able to be safely used to move and copy files that are not in an application directory.
The only disadvantage of specifying everything first in the Install dialogue using the new control field is that it will need to use a generic app/folder/file icons for the dragging and not the correct one for the item itself.
My intention is that the changes won't stop the packages working with RiscPkg or older versions of PackMan, but I can't guarantee that at the moment. PackMan itself must be able to upgrade so in the worst case there may be a period of time where PackMan is still installed to a fixed location after which it would stop working.
As this adds to the format it will also mean that packages need to be updated to support this. I can easily update the packages I maintain, will happily help any body else to update their packages, and will see to adding the new field to the autobuilder so over time as packages are rebuilt they will produced in the new format.
Thanks,
Alan
There are two areas to this.
1) The front end, you don't need to be technical to help me figure this out and this is the main part I need help with.
2) The back end. I have a proposal for what I'm thinking of doing for this, but welcome constructive criticism on this.
Of course at the end of the discussion, it would be good to know if the results will suit (most) of the people who require this functionality.
Each package can contain 0 or more items that should be allowed to set their location. e.g. Modules for !System and other such resources have only on place to go, but normal applications should be allowed to have there locations changed.
Each package also can contain dependencies which may need to be able to set their location. There are packages that are installed into one of their dependencies, so if the dependencies isn't already there, it needs to be given the position to install to first.
One of the most important user requirements is that locations can be set by drag-and-drop.
PackMan shows a list of the packages, allows you to choose one and use a button or menu option to install it. My aim is to keep this part the same.
After that, an Install dialogue is shown which gives details of the package to be installed and any dependencies it will also install. It is possible for packages to be removed to be displayed as well.
Currently you then click on Install and off it goes and downloads everything it needs and puts them on the location of your disc specified in the Paths table.
All packages come with a default path and I would like to retain that so you can do a quick install in just the same way as you do now if you are happy with where they will be put.
I'd like opinions on what the new dialogue should look like and how it should work. My initial thoughts are to list each package with it's path and if it can be modified place a draggable icon by it, but any ideas are welcome.
The design needs to take into account that as well as the most common case where there will only be one thing to drag, there may be nothing to drag or several items. I'd like to use a single dialogue for all cases if possible so there is a consistent look to the operation.
Maybe the functionality should vary a little in each case. e.g. Should the most common case of one thing to drag automatically start the install after the drag is completed? or would this cause confusion with the other cases.
Although not essential for the initial release of this it would be nice if anyone could think of a way to make the recommendations and suggestions from the package be a little more prominent and able to be added to the install from this dialogue.
PackMan's user interface doesn't support choosing multiple applications to install at once, but it is something that may come up in future, so please be aware of it.
I'm also considering adding options for more control of other aspects of the install and though I'd rather just stick to sorting out the install location now, it's worth thinking about how the design might be able to add additional options on a package by package basis in future.
I believe the back-end will need updating to make this work as smoothly as possible and am intending to add a new field to the control record that specifies which parts of the package are draggable, but any other suggestions are welcome.
The main advantage I see for this extra field are that as it's in the control record it means the paths can all be set even before anything is downloaded so once you click install all you need to look out for is it to finish.
It also simplifies the coding as there doesn't need to be any heuristics to try to figure out what should be draggable and what shouldn't. It will also mean that the apps window will be able to be safely used to move and copy files that are not in an application directory.
The only disadvantage of specifying everything first in the Install dialogue using the new control field is that it will need to use a generic app/folder/file icons for the dragging and not the correct one for the item itself.
My intention is that the changes won't stop the packages working with RiscPkg or older versions of PackMan, but I can't guarantee that at the moment. PackMan itself must be able to upgrade so in the worst case there may be a period of time where PackMan is still installed to a fixed location after which it would stop working.
As this adds to the format it will also mean that packages need to be updated to support this. I can easily update the packages I maintain, will happily help any body else to update their packages, and will see to adding the new field to the autobuilder so over time as packages are rebuilt they will produced in the new format.
Thanks,
Alan
Simon Smith
Apr 12, 2013, 11:31:21 AM4/12/13
to
In message <17c1e865-9eb0-48de...@googlegroups.com>
> The design needs to take into account that as well as the most common case
> where there will only be one thing to drag, there may be nothing to drag or
> several items. I'd like to use a single dialogue for all cases if possible
> so there is a consistent look to the operation.
> Maybe the functionality should vary a little in each case. e.g. Should the
> most common case of one thing to drag automatically start the install after
> the drag is completed? or would this cause confusion with the other cases.
Having a computer unexpectedly do something without being told when every
other time it's waited for the go-ahead is something that makes me spit
nails. Bad, /bad/ idea to even consider this in the way you have presented
here.
If you did dare to try that approach, a full undo facility would be needed.
BUT,
a way you could do it that would not raise my ire is if the system had an
'obtain and install' button as well as its 'obtain' button. For comparison
I'm thinking of Firefox's 'paste and go' when you cut a URL and paste it in
the URL bar. That shortcut changes what could be a hair-tearing annoyance
into a useful feature. So, please, if you implement this, make what's
/going/ to happen absolutely clear before the user unknowingly/accidentally
commits to something they didn't want.
I may comment on other elements of what you said later, but this one's
particularly important to me. I'm watching proceedings with some interest,
and I am grateful to you for the work you're doing.
<snip>
--
Simon Smith
When emailing me, please use my preferred email address, which is on my web
site at http://www.simon-smith.org
Alan <alan...@hotmail.com> wrote:
> I'm hoping to get some feedback on how I would implement setting the
> install location for an application at install time rather than installing
> it to a fixed location and leaving it there or moving it to another
> location.
> There are two areas to this.
> 1) The front end, you don't need to be technical to help me figure this
> out and this is the main part I need help with.
> 2) The back end. I have a proposal for what I'm thinking of doing for
> this, but welcome constructive criticism on this.
> Of course at the end of the discussion, it would be good to know if the
> results will suit (most) of the people who require this functionality.
<snip>
> I'm hoping to get some feedback on how I would implement setting the
> install location for an application at install time rather than installing
> it to a fixed location and leaving it there or moving it to another
> location.
> There are two areas to this.
> 1) The front end, you don't need to be technical to help me figure this
> out and this is the main part I need help with.
> 2) The back end. I have a proposal for what I'm thinking of doing for
> this, but welcome constructive criticism on this.
> Of course at the end of the discussion, it would be good to know if the
> results will suit (most) of the people who require this functionality.
> The design needs to take into account that as well as the most common case
> where there will only be one thing to drag, there may be nothing to drag or
> several items. I'd like to use a single dialogue for all cases if possible
> so there is a consistent look to the operation.
> Maybe the functionality should vary a little in each case. e.g. Should the
> most common case of one thing to drag automatically start the install after
> the drag is completed? or would this cause confusion with the other cases.
other time it's waited for the go-ahead is something that makes me spit
nails. Bad, /bad/ idea to even consider this in the way you have presented
here.
If you did dare to try that approach, a full undo facility would be needed.
BUT,
a way you could do it that would not raise my ire is if the system had an
'obtain and install' button as well as its 'obtain' button. For comparison
I'm thinking of Firefox's 'paste and go' when you cut a URL and paste it in
the URL bar. That shortcut changes what could be a hair-tearing annoyance
into a useful feature. So, please, if you implement this, make what's
/going/ to happen absolutely clear before the user unknowingly/accidentally
commits to something they didn't want.
I may comment on other elements of what you said later, but this one's
particularly important to me. I'm watching proceedings with some interest,
and I am grateful to you for the work you're doing.
<snip>
--
Simon Smith
When emailing me, please use my preferred email address, which is on my web
site at http://www.simon-smith.org
Martin Bazley
Apr 13, 2013, 6:29:10 AM4/13/13
to
The following bytes were arranged on 12 Apr 2013 by Alan :
> Each package also can contain dependencies which may need to be able
> to set their location. There are packages that are installed into one
> of their dependencies, so if the dependencies isn't already there, it
> needs to be given the position to install to first.
Take StrongED's mode packages, for example. Those are distributed as a
shell !StrongED application, so obviously it makes no sense to install
that anywhere but over the existing copy of !StrongED.
The current 'install and move' system breaks this just as badly, because
if you've moved !StrongED then you have to manually move every mode
package you install to the same place. (Also, what happens if you move
!StrongED with one or more mode packages already installed inside it?)
So, if we're adding a 'list of draggables' control field, I think some
way to refer to a 'draggable' in a separate package (which you would
hope is included in the dependencies) in the default install location
would be useful. That way, the shell application wouldn't be draggable,
but would be automatically installed in the correct place. The current
directory hierarchy/Paths file standard isn't compatible with this, but
then again I think that needs to go away anyway.
> I'd like opinions on what the new dialogue should look like and how it
> should work. My initial thoughts are to list each package with it's
> path and if it can be modified place a draggable icon by it, but any
> ideas are welcome.
Not workable, unless you're going to change the RiscPkg standard to make
it impossible to install more than one thing out of the same package.
There is a many-to-many relationship between packages and draggable
components.
I think you'd have to separate the list of packages to install and the
list of components of those packages (which may be less than, equal to
or greater than the number of packages).
> It also simplifies the coding as there doesn't need to be any
> heuristics to try to figure out what should be draggable and what
> shouldn't. It will also mean that the apps window will be able to be
> safely used to move and copy files that are not in an application
> directory.
Yes, these are the two main reasons I don't think attempting to proceed
further with a package format which doesn't include a list of things to
be dragged is realistic. But since we're agreed that changes to the
format will be necessary, and these will undoubtedly be painful, could I
ask you to delay them until we can agree on as many other changes as
possible (e.g. getting rid of the Apps directory and its friends and
moving everything into a subdirectory called something like 'Files')?
It would be nice to limit the number of major rounds of package updating
to one.
Also, when we have a new format, I can probably help you with the
updating process. I've built packages before, and it shouldn't be too
difficult.
> The only disadvantage of specifying everything first in the Install
> dialogue using the new control field is that it will need to use a
> generic app/folder/file icons for the dragging and not the correct one
> for the item itself.
May I suggest the Wimp sprite named - ahem - "package"?
> My intention is that the changes won't stop the packages working with
> RiscPkg or older versions of PackMan, but I can't guarantee that at
> the moment. PackMan itself must be able to upgrade so in the worst
> case there may be a period of time where PackMan is still installed to
> a fixed location after which it would stop working.
I wouldn't worry too much about !RiscPkg - as far as I'm concerned it's
dead software. The fact that it only supports fixed location installs
is its biggest problem, and incompatibility introduced this way is
arguably just another manifestation of that.
--
__<^>__ "Start off every day with a smile and get it over with."
/ _ _ \ - W.C. Fields
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
> Each package also can contain dependencies which may need to be able
> to set their location. There are packages that are installed into one
> of their dependencies, so if the dependencies isn't already there, it
> needs to be given the position to install to first.
shell !StrongED application, so obviously it makes no sense to install
that anywhere but over the existing copy of !StrongED.
The current 'install and move' system breaks this just as badly, because
if you've moved !StrongED then you have to manually move every mode
package you install to the same place. (Also, what happens if you move
!StrongED with one or more mode packages already installed inside it?)
So, if we're adding a 'list of draggables' control field, I think some
way to refer to a 'draggable' in a separate package (which you would
hope is included in the dependencies) in the default install location
would be useful. That way, the shell application wouldn't be draggable,
but would be automatically installed in the correct place. The current
directory hierarchy/Paths file standard isn't compatible with this, but
then again I think that needs to go away anyway.
> I'd like opinions on what the new dialogue should look like and how it
> should work. My initial thoughts are to list each package with it's
> path and if it can be modified place a draggable icon by it, but any
> ideas are welcome.
it impossible to install more than one thing out of the same package.
There is a many-to-many relationship between packages and draggable
components.
I think you'd have to separate the list of packages to install and the
list of components of those packages (which may be less than, equal to
or greater than the number of packages).
> It also simplifies the coding as there doesn't need to be any
> heuristics to try to figure out what should be draggable and what
> shouldn't. It will also mean that the apps window will be able to be
> safely used to move and copy files that are not in an application
> directory.
further with a package format which doesn't include a list of things to
be dragged is realistic. But since we're agreed that changes to the
format will be necessary, and these will undoubtedly be painful, could I
ask you to delay them until we can agree on as many other changes as
possible (e.g. getting rid of the Apps directory and its friends and
moving everything into a subdirectory called something like 'Files')?
It would be nice to limit the number of major rounds of package updating
to one.
Also, when we have a new format, I can probably help you with the
updating process. I've built packages before, and it shouldn't be too
difficult.
> The only disadvantage of specifying everything first in the Install
> dialogue using the new control field is that it will need to use a
> generic app/folder/file icons for the dragging and not the correct one
> for the item itself.
> My intention is that the changes won't stop the packages working with
> RiscPkg or older versions of PackMan, but I can't guarantee that at
> the moment. PackMan itself must be able to upgrade so in the worst
> case there may be a period of time where PackMan is still installed to
> a fixed location after which it would stop working.
dead software. The fact that it only supports fixed location installs
is its biggest problem, and incompatibility introduced this way is
arguably just another manifestation of that.
--
__<^>__ "Start off every day with a smile and get it over with."
/ _ _ \ - W.C. Fields
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
Tony Moore
Apr 13, 2013, 7:33:06 PM4/13/13
to
On 12 Apr 2013, Alan <alan...@hotmail.com> wrote:
[snip]
> I'd like opinions on what the new dialogue should look like and how it
> should work. My initial thoughts are to list each package with it's
> path and if it can be modified place a draggable icon by it ...
I agree. My suggestion is that the user should
select one (or more) of the packages in the main Packman window
click the 'Install/Upgrade' button in the main window, to open a new
window giving proposed installation details of the first selected
package
the window lists the proposed paths of the application, and each of
its dependencies. It may also list the proposed paths of recommended
installs
radio buttons allow the choice of installation of
[*] package and dependencies
[*] package, dependencies and recommended installs.
if the application has not been installed before, the proposed path
is the PackMan default. If the user has previously installed the
package, the proposed path is its present location (which may, or not
be, the PackMan default).
next to each path, an icon may be dragged to a new location, thus re-
setting the path. If it is not permitted for the user to relocate any
item, its icon is greyed-out, and doesn't respond to dragging.
the user clicks 'Accept' to accept the paths in the current window,
and move on to the next package window
the package window also contains buttons:
'Accept all' which accepts the proposed paths for all of the
selected packages (ie without visiting their windows)
'Back' which enables review of previous package windows
'Remove' which removes the current package from the installation
sequence
'Cancel' which cancels all input, and exits the installation
clicking 'Accept', on the last package window, or clicking 'Accept
all', at any point, initiates the download, and installation of all
packages.
after the installation of all packages, a new window opens confirming
the successful installation, and allowing the user the option of
viewing the location of the applications, and/or running them (at
present, after a download, the window confirms that it is 'Done', and
offers a 'Close' button, but there is no indication as to where the
application may actually be found).
Tony
[snip]
> I'd like opinions on what the new dialogue should look like and how it
> should work. My initial thoughts are to list each package with it's
I agree. My suggestion is that the user should
select one (or more) of the packages in the main Packman window
click the 'Install/Upgrade' button in the main window, to open a new
window giving proposed installation details of the first selected
package
the window lists the proposed paths of the application, and each of
its dependencies. It may also list the proposed paths of recommended
installs
radio buttons allow the choice of installation of
[*] package and dependencies
[*] package, dependencies and recommended installs.
if the application has not been installed before, the proposed path
is the PackMan default. If the user has previously installed the
package, the proposed path is its present location (which may, or not
be, the PackMan default).
next to each path, an icon may be dragged to a new location, thus re-
setting the path. If it is not permitted for the user to relocate any
item, its icon is greyed-out, and doesn't respond to dragging.
the user clicks 'Accept' to accept the paths in the current window,
and move on to the next package window
the package window also contains buttons:
'Accept all' which accepts the proposed paths for all of the
selected packages (ie without visiting their windows)
'Back' which enables review of previous package windows
'Remove' which removes the current package from the installation
sequence
'Cancel' which cancels all input, and exits the installation
clicking 'Accept', on the last package window, or clicking 'Accept
all', at any point, initiates the download, and installation of all
packages.
after the installation of all packages, a new window opens confirming
the successful installation, and allowing the user the option of
viewing the location of the applications, and/or running them (at
present, after a download, the window confirms that it is 'Done', and
offers a 'Close' button, but there is no indication as to where the
application may actually be found).
Tony
Tony Moore
Apr 14, 2013, 6:29:39 PM4/14/13
to
On 13 Apr 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
[snip]
> the user clicks 'Accept' to accept the paths in the current window,
> and move on to the next package window
On further thought, I believe that the 'Accept' button can be omitted,
and the arrangement of buttons simplified, as follows:
'Next' (select click) cycles through the selected package windows
(adjust click: 'previous'). If only one package is to be installed
'Next' is greyed-out.
'Remove' removes the current package from the selection.
'Install' initiates the download and installation of the selected
package(s), to the path(s) chosen in the package window(s).
'Cancel' exits the process, leaving all paths unchanged.
Tony
[snip]
> the user clicks 'Accept' to accept the paths in the current window,
> and move on to the next package window
and the arrangement of buttons simplified, as follows:
'Next' (select click) cycles through the selected package windows
(adjust click: 'previous'). If only one package is to be installed
'Next' is greyed-out.
'Remove' removes the current package from the selection.
'Install' initiates the download and installation of the selected
package(s), to the path(s) chosen in the package window(s).
'Cancel' exits the process, leaving all paths unchanged.
Tony
Alan
Apr 15, 2013, 8:24:49 AM4/15/13
to
On Saturday, 13 April 2013 11:29:10 UTC+1, Martin Bazley wrote:
> The following bytes were arranged on 12 Apr 2013 by Alan :
>
> > Each package also can contain dependencies which may need to be able
> > to set their location. There are packages that are installed into one
> > of their dependencies, so if the dependencies isn't already there, it
> > needs to be given the position to install to first.
>
> Take StrongED's mode packages, for example. Those are distributed as a
> shell !StrongED application, so obviously it makes no sense to install
> that anywhere but over the existing copy of !StrongED.
>
> The current 'install and move' system breaks this just as badly, because
> if you've moved !StrongED then you have to manually move every mode
> package you install to the same place. (Also, what happens if you move
> !StrongED with one or more mode packages already installed inside it?)
This does work, because I implemented the move to look at what's installed
> The following bytes were arranged on 12 Apr 2013 by Alan :
>
> > Each package also can contain dependencies which may need to be able
> > to set their location. There are packages that are installed into one
> > of their dependencies, so if the dependencies isn't already there, it
> > needs to be given the position to install to first.
>
> Take StrongED's mode packages, for example. Those are distributed as a
> shell !StrongED application, so obviously it makes no sense to install
> that anywhere but over the existing copy of !StrongED.
>
> The current 'install and move' system breaks this just as badly, because
> if you've moved !StrongED then you have to manually move every mode
> package you install to the same place. (Also, what happens if you move
> !StrongED with one or more mode packages already installed inside it?)
inside the the !StrongED directory and move them as well. The paths file
contains the location of the !StrongED directory (not the individual modes
files) so when is installs a mode later it puts them in the new !StrongED
location.
>
> So, if we're adding a 'list of draggables' control field, I think some
> way to refer to a 'draggable' in a separate package (which you would
> hope is included in the dependencies) in the default install location
> would be useful. That way, the shell application wouldn't be draggable,
> but would be automatically installed in the correct place. The current
> directory hierarchy/Paths file standard isn't compatible with this, but
> then again I think that needs to go away anyway.
>
even if there wasn't one. I'm not sure that you need to specify draggables
that live in another package. If you need the other location, then the
other package is a dependency, and that package would be stating that
it's draggable.
i.e. For StrongED modes, the StrongED modes itself would just say install
into the !StrongED path. If would not contain the new Draggable
field. !StrongED is also set to install into the !StrongED path and
it marks the !StrongED path as draggable. The installer will look
at the dependencies and as !StrongED is draggable will add the
!StrongED path to the dialogue to allow it to be changed.
>
>
> > I'd like opinions on what the new dialogue should look like and how it
> > should work. My initial thoughts are to list each package with it's
> > path and if it can be modified place a draggable icon by it, but any
> > ideas are welcome.
>
> Not workable, unless you're going to change the RiscPkg standard to make
> it impossible to install more than one thing out of the same package.
> There is a many-to-many relationship between packages and draggable
> components.
>
> I think you'd have to separate the list of packages to install and the
> list of components of those packages (which may be less than, equal to
> or greater than the number of packages).
I think I see what you are saying, I believe I'm thinking of Draggable
>
> > I'd like opinions on what the new dialogue should look like and how it
> > should work. My initial thoughts are to list each package with it's
> > path and if it can be modified place a draggable icon by it, but any
> > ideas are welcome.
>
> Not workable, unless you're going to change the RiscPkg standard to make
> it impossible to install more than one thing out of the same package.
> There is a many-to-many relationship between packages and draggable
> components.
>
> I think you'd have to separate the list of packages to install and the
> list of components of those packages (which may be less than, equal to
> or greater than the number of packages).
for where you are saying component and only specifying Draggable
components. i.e. The Draggable attribute is used to specify what parts
of the Package can be dragged and can be missing if everything needs
to go to a fixed place, one item if it's only one and multiple items if
there's more than one thing that can have it's location set.
>
> > It also simplifies the coding as there doesn't need to be any
> > heuristics to try to figure out what should be draggable and what
> > shouldn't. It will also mean that the apps window will be able to be
> > safely used to move and copy files that are not in an application
> > directory.
>
> Yes, these are the two main reasons I don't think attempting to proceed
> further with a package format which doesn't include a list of things to
> be dragged is realistic.
I think we completely agree on this point. My analysis is anything else
> > It also simplifies the coding as there doesn't need to be any
> > heuristics to try to figure out what should be draggable and what
> > shouldn't. It will also mean that the apps window will be able to be
> > safely used to move and copy files that are not in an application
> > directory.
>
> Yes, these are the two main reasons I don't think attempting to proceed
> further with a package format which doesn't include a list of things to
> be dragged is realistic.
would be an over complication, if it would work at all. I know it get's
lost in other things, but the current package format is open and extensible
which is why I think it doesn't need replacing.
> But since we're agreed that changes to the
> format will be necessary, and these will undoubtedly be painful, could I
> ask you to delay them until we can agree on as many other changes as
> possible (e.g. getting rid of the Apps directory and its friends and
> moving everything into a subdirectory called something like 'Files')?
to present these things in such a way that I don't end up with another
round of complaints about it not being identical to a Save As box.
Technically, once the paths have been specified I just need to update the
Paths file and run the current installer. This particular change doesn't
need changes to the packaging back-end, just the user interface and the
Package format.
>
> It would be nice to limit the number of major rounds of package updating
> to one.
themselves need to be modified should be minimized.
Before any updating is done I definetely want to review the SysVars/Sprites
handling to see if there is anything that should be done to the
package format in this area. This does include investigating your
idea of dumping them altogether and using Look At instead.
> Also, when we have a new format, I can probably help you with the
> updating process. I've built packages before, and it shouldn't be too
> difficult.
necessarily exactly what you want.
>
> > The only disadvantage of specifying everything first in the Install
> > dialogue using the new control field is that it will need to use a
> > generic app/folder/file icons for the dragging and not the correct one
> > for the item itself.
>
> May I suggest the Wimp sprite named - ahem - "package"?
for each application. The app/folder/file idea was so you would
get a better idea of what it was you were dragging. Just using
package would be a lot simpler.
>
> > My intention is that the changes won't stop the packages working with
> > RiscPkg or older versions of PackMan, but I can't guarantee that at
> > the moment. PackMan itself must be able to upgrade so in the worst
> > case there may be a period of time where PackMan is still installed to
> > a fixed location after which it would stop working.
>
> I wouldn't worry too much about !RiscPkg - as far as I'm concerned it's
> dead software. The fact that it only supports fixed location installs
> is its biggest problem, and incompatibility introduced this way is
> arguably just another manifestation of that.
>
selecting multiple packages at once and marking packages so they don't
upgrade, so the question is really aimed to see if there are people
who need this functionality or anything else from !RiscPkg now.
PackMan has always been aimed as an alternative to !RiscPkg as !PackMan
was written to make the user interface to packages easier (in my
opinion). To make it a replacement is a new step which is why I'm
considering the consequences very carefully.
Regards,
Alan
Alan
May 16, 2013, 7:52:45 AM5/16/13
to
On Friday, 12 April 2013 13:33:16 UTC+1, Alan wrote:
> I'm hoping to get some feedback on how I would implement setting the install location for an application at install time rather than installing it to a fixed location and leaving it there or moving it to another location.
>
Thanks for the people who replied to this thread. I've now created a little test application and some screen shots that show how I think it should be done.
> I'm hoping to get some feedback on how I would implement setting the install location for an application at install time rather than installing it to a fixed location and leaving it there or moving it to another location.
>
These are located at:
https://sites.google.com/site/alansriscosstuff/testdrag
All feedback would be greatly appreciated.
0 new messages