|
VVV_Easy_Symenu Posts: 159
30/01/2016
|
Hello,
Not all SPS apps have the same quality or trust so I would like to propose some standardization in the names and licenses for the apps SPS, but not for repeat the SPS App: (1)
a) Freeware, OpenSource - GNU License:
- 1) SPS app downloaded from the author web or a standard repository (FossHub, SnapFiles, etc): "App" (Nothing to add)
- 1a) If the app has two versions depending on the architecture then "App (x86)" "App (x64)"
- 2) SPS app downloaded from the author web but made with a specific diferent portable version of the original program: "App Portable"
- 3) SPS app downloaded from the SPS publisher "disk" (iCloud, Drive, etc): "App Custom"
- 4) SPS app made with PortableApps.com: "App PortableApps"
b) Crippleware: SPS app made with a limited version of the original program: "App Free" or "App Lite"
c) Adware: SPS app made with a version of the original program with web advertisements: "App Adware"
d) Shareware (use limited in the time) -> Avoid
e) Proprietary Software (paid software) -> Avoid
As always, Gian has the last word for this proposition.
(1) Note: After the discussion of message "User preference 'Poll'" I am not sure.
.
edited by VVV_Easy_Symenu on 31/01/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
31/01/2016
|
Well I'd like very much if this forum is considered a democratic place where we can talk and we can take decisions all together :-) Often I have the last word only because I'm the only person to have a triple perspective:
- the perspective born from the discussion
- the one forced by the software (intrinsic limits, consistency, time to implement)
- the one suggested by a long time path I'm creating in my mind (yes I'm starting to talk about that with someone but it is too raw to make it public... anyway great things are in project)
The naming convention is appreciable but I have some doubts.
1) I can't understand why the program name should contain the license information. We have a special license field to contain this information.
2) I strongly prefer to respect the original name. So if an author decides that his program is called App why I should call it App Custom if the download comes from my Dropbox area? What if tomorrow the download becomes available from the author web site? Will I change the name?
3) We have a very large library and renaming the already available programs is not good.
Let's see why changing the name of a program is not a good thing.
I create this SPS architecture based on the file system. You have a single file for each SPS. The file name is similar to the program name that is the key to univocally identify a certain SPS. If we change a key, i.e. a program name, we break the chain that SyMenu recognize to propose a program update.
A simple example to explain better this scenario.
In my local SyMenu installation I have the Paint.NET Portable SPS installed.
When I added the Paint.NET Portable (x64) to the collection I should have change the first SPS name in Paint.NET Portable (x86).
But I haven't changed it otherwise in my local SPS list I would have this situation:
Paint.NET Portable - installed and outdated but the SPS Manager doesn't alert me because this branch is dead
Paint.NET Portable (x64) - new available
Paint.NET Portable (x86) - new available, and this is the new branch of my old installation.
In my opinion is not a good thing break a program branch, because otherwise we force the users to lost their configuration to install the new updated branch.
This is a great error I did when I decided to tie the SPS keys with the program names...
To finish.
My vote goes for a strict program naming for every new SPS but I partially agree your proposal.
- Using the original program name. Ok
- (x64) (x86) depending on the program architecture. Ok
- App portable when a not portable version exists. We can adopt it. It's good.
- App custom depending on the repository. Not at all unless before loading on a personal repository, the package has been changed in some way (is it acceptable to change a package in this way??? This is another topic).
- App PortableApps. I don't know, we already give credits to PortableApps in the author field. What are others' ideas?
- License inside the name. I don't agree with that unless the original name already carries some license references (free, lite, adware)
- Avoid shareware and proprietary. I perfectly agree with you.
Another interesting topic is: what do we do when in our opinion another editor publishes a not so good SPS?
For sure please don't publish a duplication. Let's try to discuss about the reasons of both and try an agreement. Our users will thank us!
What do you all think about these thoughts?
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
31/01/2016
|
I don't like very much the forum as a democratic place because they tend to turn into long discussions.
On the contrary, I am firmly in favor of the figure "Benevolent dictator for life" for that I prefer to consider the forum as help and brainstorming to inspire Gian Luca, the "BDFL of SyMenu"  So, Gian, you do not have "a vote" you have the "decision" ("the last word"  ).
Returning to the subject I attempt to summarize the decision. Only for the new SPS App:
- Using the original program name.
- (x64) (x86) depending on the program architecture.
- Portable when a not portable version exists.
- License inside the name: Only when the original name already carries some license references (Free, Lite, Adware)
- Avoid shareware and proprietary.
I opened this thread because I think it's important use the original source for creating the SPS App for the acknowledgment of Freeware/OpenSource authors and for avoid the viruses so I prefer to make my _CustomCache SPS that to use external sources (but perhaps the proposal has been complicated further as it advanced).
About the opinion of other SPS App, I have written a couple of publishers and they are receptive. No problem for this part.
|
|
|
link
|
|
sl23 Posts: 285
01/02/2016
|
These "rules" are the ones I've tried to follow as closely as possible and I completely agree they are necessary.
Gian, if a publisher creates a bad sps, then isn't that the point of the Report a broken sps link? Personally, I think this should be renamed to Author's email, or Email Author, or Contact Author, for more clarity. What do you say?
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
01/02/2016
|
Actually the "Report a broken SPS" born as an easy way for final users that aren't able to download/install/execute a program managed through an SPS.
It's a sort of alarm for us editors to check our SPS and discover what's wrong with it. Usually it's a broken link or the author web site temporarily off line.
The users are starting to use it as an way to have a newer SPS version because the related program has been just released. Great SyMenu users, I love you!!
You are suggesting to use it as a way to directly contact the editor and suggest him to conform its SPS with our rules. Mega great!!
In this way we should reach uniformity in a short time.
It's true, with all these new purposes the label Report a broken SPS is a bit outdated.
What do you suggest considering that the message must be obvious to base users above all?
We can't speak about mail because a lot of editors use a web contact form such as http://contactbyweb.com/
|
|
|
link
|