Official Release - CMOS
Chris Hall (132) 3554 posts |
it seems that you are taking that choice away from them. No. If they move it, then the AddApp that I have included will simply not do anything (I don’t think it will even produce an error). |
nemo (145) 2546 posts |
Without becoming embroiled in this particular belief system debate, the Cerilica MMK keyboard came with a pile of support modules and applications with various mandated, recommended or suggested destinations, so I wrote an installer. That installer allowed the user to choose which items to install and those that were selected defaulted to the recommended installation point but, crucially, the user could drag each icon somewhere else to change to installation point. See here for a screenshot. I don’t see why package management systems couldn’t do the same thing, remembering where the user chose to install a package if it isn’t the default location. |
Rick Murray (539) 13840 posts |
Thing is, we are asking the user to install something, find it (in the filesystem as opposed to “Apps”) and then move it. Instead of, you know, something logical like drag-to-install in the package manager to put the app in the desired place in the first place. |
Trevor Johnson (329) 1645 posts |
For the benefit of anyone else browsing via a NSFW firewall, if it’s poorly configured, that link may also be accessible via https, believe it or not! |
Alan Buckley (167) 232 posts |
I’ve now created a small test application which shows my thoughts on a new install window in PackMan to allow drag-and-drop of install locations. The application and some screenshots are at: https://sites.google.com/site/alansriscosstuff/testdrag It would be great if people can look at this and see if this will fulfil their requirement for setting the install location of applications. If not, suggestions on how it can be improved would be greatly appreciated. If you are already OK with how PackMan works have a quick look as well to ensure it’s not going to spoil it for you. For those who don’t think PackMan is a “RISC OS” package manager, will this new window be a positive step in the right direction? Thanks, |
Jess Hampshire (158) 865 posts |
Will you be able to drag over the top of a currently unmanaged app to upgrade it? Could the option for the drag to create a shortcut (and the install carry in to old way) be added.? |
Alan Buckley (167) 232 posts |
It will treat this as a conflict in the same way as it does now if the application already exists at the install location. Recent PackMan releases do allow you to hit backup and retry to replace it.
I hadn’t thought of doing this, but I don’t see anything to prevent me adding it. How would you see it working? A global option in a choices screen, something for each draggable component, adjust drag or something else? |
nemo (145) 2546 posts |
You will need an explicit dot separator on the end of the path (as per my earlier screenshot) so that the user can substitute a path variable instead – LikeThis: |
Bryan Hogan (339) 592 posts |
Looks much better, with one huge caveat: Small scrolling regions inside fixed size dialogue boxes – no no no no no no! Evil UI feature guaranteed to lead to frustration! If the window has variable sized content then give it scrollbars and a resize icon. This avoids problems with bits getting cut off on small screens or looking silly on big screens. More minor issue, what does “Apply” mean on the buttons? Make it Install or Upgrade so it is obvious what is going to happen. |
Alan Buckley (167) 232 posts |
I was going to add the dot if needed (i.e. now then the path ended with a colon) when the apply button was selected. Do you still think it adds something to show the dot? Thanks for your screen shot by the way, I had originally one writable field that included the leaf as well and was then going to have to check it hadn’t changed. Your way of doing it seems much better. |
Alan Buckley (167) 232 posts |
I can see your point here – I wasn’t happy with the size of the component section, but wanted to make sure it fit on a smaller screen.
I was unsure on this because it may mean you have to scroll to find the apply/cancel button, but thinking on it some more that’s not necessarily a bad thing as it means users need to have scanned what is happening before proceeding and even this won’t be necessary in the majority of the cases. Would it be OK to keep the Package list in a scrolling window and expand the rest of the window, or do both areas need doing? I’m not quite sure what to replace the package list area with if it’s not a scrolling list as I’d like user to be able to remove things from this area if they change their mind.
The top scrolling list shows what actions are going to happen on possibly multiple packages so there could be packages installed, updated and removed at the same time. If there is a better thing to call it or a better way to indicate what it does I’d welcome ideas. |
nemo (145) 2546 posts |
Not necessarily. :-)
I agree, and an improved UI idiom has been discussed before, but is more work for the poor beleaguered programmer: Give the scrolling pane a resize icon and then resize the parent (moving and resizing icons as necessary) to take account of the changing pane size. More work, but a nicer interface.
Those are in the parent, only the variable sized list should be in the scrolling pane.
The button should say what it will do – if it’s only going to install things, it should say “Install”, if it’s only going to remove, “Remove”. Otherwise, “Update” appears to cover all eventualities. |