Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
70 user(s) are online (45 user(s) are browsing Forums)

Members: 0
Guests: 70

more...

Support us!

Headlines

Report message:*
 

Re: Updater locking up

Subject: Re: Updater locking up
by ktadd on 2021/1/20 18:33:55

@amigakit
First off, I really appreciate all the effort that is being undertaken to provide the enhancer package which is providing us with frequent and continued enhancement to the AmigaOS4 and Classic AmigaOS experience. Great work!

Now I'd like make some comments and suggestions based on over 20 years of experience as a Quality Engineer/Manager with a large test equipment manufacture.

I understand there are some OS components that are not easily renamed due to integreation into the OS. Such things as the sound.datatype and to me that's fine. From a users point of view these types of changes need to be able to be easily identified. I have some suggestions below on how to do that.

Having said that, I beleive that using the same name should only occur when there is a compelling reason to do so. In the case of Format and Clock, as examples, I'm not sure what the compelling reason would be. As we have seen with the latest release of the OS4 update2, especially with Clock, the Enhancer version gets overwritten. This causes the user the hastle of having to re-install the enhancer component. Not a very nice thing to do to the user.
I'm not understanding what the issue is with renaming these types of components to something like EClock (Enhancer Clock) and Formater?
This would aviod these types of conflicts. In most cases this has been done and it's great.

For example, MultiView and MultiViewer. This is great because I can still use both these applications. I have MultiView and MultiViewer configured differently and I use the one that is best configure for my particular need at the time.

I apprecaite the argument and the flexibility that a user can rename some of the enhancer components but this then causes a problem with updater knowing about them and causes pain for the user when they want to update. Why not just avoid that issue by naming them differently where possible?

I also appreciate the argument that you can programs with the same name in different places, however this then causes a problem with the AppDir: feature in the OS. You will never be sure which version is run when you use AppDir: and there may be scritps written that depend of certiain features of one version of the program and not the other version.

I appreciate the fact that the user can choose not to install the enhancer version. However, this can deprive the user of the great enhancements it does provide and why should a user have to make that choice if it's not necessary and simply choosing a different name would solve the issue and allow your enhancer features to be more widely accepted and used. I as a user like having the option of using the enhanced or non enhanced version.

Last I'll address the version issue. As a user I'm not as concerned about the version number being similiar to non-enhancer equivalents but am more concerned about being able to easily identify and Enhancer version vs. an Non-Enhancer version. The black icons help with some programs but some people may not like them and it doens't help with things that don't have an icon.

Here are a couple of suggestions that I think could help this issue. Implementing one or more of these would solve the issue.

1. Include an indicator that it is an Enhancer or A-EON version in the version string like you did with the Format program. That way I can right click on the icon, select Version and easily identify that it's an Enhancer supplied program.

2. Add a file comment that indicates it's part of the Enhancer package.

3. Add a column to Updater that indicates the Enhancer component will replace an existing AmigaOS component. or have a filter selection in the drop down menu that will list only the components that replace existing OS components. Then at least the user can easily identify those components if an update causes issues. This would also provide the user the ability to know which components to check if another AmgiaOS update is released.

I hope you will take these inputs and suggestions into consideration as they are easy things to do and will produce a lot of good will from your users.

Once again, I really apprecaite the contribution and effort over the last 5 years. It has kept things moving during the dry spell of OS Updates and provides a valuable service to the comunity. Keep up the good work

@All
Sorry for such a long post.

Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project