|
VVV_Easy_Symenu Posts: 159
14/01/2018
|
Hello,
Often when you browse the SyMenu menus you realize that you have an app that you have not used for a long time and you want to uninstall it quickly.
Now you have to go to "Get New Apps" to find, mark and uninstall it.
I propose a new feature that can be done by several ways ... to discuss:
1) New "Action Modifier" = "Uninstall". It can be in two ways:
- With a new Windows pop-up that directly asks to the user
- Openning the "Get New Apps" with the app ticketed (but ¿what happens when the SyMenu ítem isn't a SyMenu Suite app?)
2) New option "Uninstall" in the "Configure Ítem" window. So, by using the "Action Modifier- Configure Item" you can reach quickly the uninstall option. This has the advantage the resolves the problem of try uninstall a no SyMenu Suite app but .... passing the problem to the "Configure Item" window.
For discuss ... 
edited by VVV_Easy_Symenu on 14/01/2018
|
|
|
link
|
|
sl23 Posts: 285
14/01/2018
|
Surely it's a simple matter of deleting the apps folder and the entries in SyMenu?
Regardless of the apps origins, this will effectively delete anything.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
15/01/2018
|
Indeed your second option already works even if it's limited to the SPS programs.
Let's see the full procedure with its relative effects:
- open the context menu
- select the Action modifier - Configure Item
- click on the required item (must be an SPS one)
- the configuration form opens with the clicked item selected
- delete the item from the list
- save and close
At this point the item has been logically removed but the related physical folder still exists on your FS.
Anyway the first time you enter inside the Get new apps form, the orphan entries will be trashed from the file system too.
Why does this work only for SPS?
Because, normally, it's really difficult to determine if a folder and its related program could be removed from the file system.
Case 1)
Think about a program that has more than one linked item. The removal of one of them can't cause the automatic program uninstallation.
A real example: I have several programs launched through the Java executable. So my main program is actually the java.exe executable and the real program is only linked in the command line. If I remove one of this entry because I don't want the program anymore, the system will remove the java executable and not the linked program.
Case 2)
I linked a regular program from my FS to a SyMenu item. With "regular" I intend an installed one.
If I remove the logical item I don't want to remove the program and it would be even worst than the case 1) because a regular installed program can be removed only with a regular uninstallation.
I don't know if we can have other cases but they are enough for me.
Why can I remove an SPS instead?
Because the SPS thing are almost under my control. I know where they are located, I know that they was installed by SyMenu, I know how many logical entries they have. This simplify the management of logical and physical objects. But guys, if you engage in this mission very hard, you'll find a lot of way to create misalignment in the SPS too.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
15/01/2018
|
So, with your information, I think that the best way to implemente the new feature may be the new Action Modifier = "Uninstall" with this procedure:
- open the context menu
- select the new Action modifier - "Uninstall"
- click on the required ítem and then:
a) If the item is from SyMenu, Nirsoft or Sysinternal program suite:
- The "Remove program" window (now is child of "Get new apps" but I supose that may be easy to profit the code) opens asking to the user to confirm the standart SyMenu suite uninstall
b) In other case (not from the standart suites). It will be redundant with the actual Action modifier - "Configure Item" (to profit again the code):
- the configuration form opens with the clicked item selected
- delete the item from the list -> Now is in the user task to verify the origin of the ítem, for instance if is a Web URL no more actions are needed.
- save and close
.
edited by VVV_Easy_Symenu on 15/01/2018
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
16/01/2018
|
@VVV_Easy_Symenu I don't like very much this solution because:
- the new action modifier should have two different behaviors depending on the item. This kind of discrepancies are difficult to justify or explain to the user so I always avoid them in SyMenu: the gold rule is consistency above all;
- the a) case, compared to the b) case, spares only a single operation to the user (the DEL key pressing) and it's a too little benefit to justify a full new action modifier implementation;
- one rule we should follow to maintain consistency in SyMenu is that the context menu allows to do something (actions), the configuration form allows to do something but mainly to manage your menu (move, add, rename, delete, and so on). I don't intend to include managing activities in the context menu.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
16/01/2018
|
Ok, so, without a new Action Modifier the new feature would be in the configuration form with this procedure:
- open the context menu
- select the new Action modifier - "Configure Item"
- click on the required item
- the configuration form opens with the clicked item selected and then:
a) If the item is from SyMenu, Nirsoft or Sysinternal program suite:
a1) The user will find in the configuration form a "Uninstall button" that shows the "Remove program" window (now is child of "Get new apps") asking to the user to confirm the standart SyMenu suite uninstall of this entry.
or
a2) The user must delete all the items linked with the SyMenu App. After he must enter inside the Get new apps form and , the orphan entries will be trashed from the file system too.
b) In other case (not from the standart suites). The user must delete the item from the list and is the user task to verify the origin of the ítem, for instance if is a Web URL no more actions are needed.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
17/01/2018
|
Even this way it doesn't work because we have inconsistencies at the UI level.
When the user enters the configuration form, he doesn't know if a certain item is belonging to an SPS suite or not. He can recognize it only analyzing the executable path. In this case a different explicit action (uninstall vs. delete logical item) should appear according to its nature.
It's confusing.
You can assert that the two SyMenu behaviors towards the file system could be confusing the same (SPS case it cleans up, not SPS it leaves the program) but, at least, it's not a UI problem and it's an issue that remains unsolved with your solution too.
Let's analyze your request from another point of view.
Since the SPS introduction I noted that more and more users are approaching SyMenu because of the integrated applications (SPS). I received support requests from users that didn't have any idea that a custom program can be added or that a configuration form even exists. A normal user adds, updates and removes items only from the get new apps form.
Because of this I'm starting to consider the configuration form like an advanced feature.
This is the reason because I implemented the options form access, directly from the context menu too (you know that it exists, don't you? It's so handy...).
I'm even thinking to remove the configuration form from the base contextual menu configuration, leaving it only for the expert mode or the custom mode.
And this is the reason for which my recent developing efforts are so concentrated on the SPS instead of the other SyMenu fields.
Thus if I have to choose among an UI and FS inconsistencies vs. a FS inconsistency alone, I prefer the latter, because, more likely, it affects an advanced user rather than a normal one that doesn't use the custom item but can occasionally use the configuration form (to move or reorganize its items).
For these reasons I would leave everything as it is now.
This is the action flow:
- open the context menu;
- select the new Action modifier - "Configure Item";
- click on the required item;
- the configuration form opens with the item selected;
- click on the keyboard DEL button;
- click on the form Save button.
From a logical point of view the item will be removed
From a FS point of view we have two cases:
- SPS - the first time you enter the SPS Manager form the system scans your items and removes the installed one from the FS if it's no more available as a logical item;
- Custom - you remain with an orphan program, but it's not an easily solvable issue.
I know that the second case is really annoying but I have a new idea to help the FS managing.
We already have a tool that scans a folder and its subfolders searching for programs. It's the batch importer. I can implement inside it, a new search option to exclude any program already linked with a SyMenu logical item.
Naturally an excluded item will exclude any of its subfolders too.
The remain found items will be the real orphan programs and the programs linked in strange ways (as a command line argument for example). Anyway the number of elements to manage will decrease dramatically and helps a lot to maintain the FS aligned.
Plus I can implement a function to open the selected folder directly from inside the batch import form. With the folder opened you can easily delete the entire program if it is your intention.
What do you think?
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
17/01/2018
|
Well, I'm a little bit lost in the discussion so I will try to explain the initial idea with a new approach but, if it does not seem useful, don't worry, this does not go very far .
First, almost all my items are Web URL's or SPS Suite applications.
When I want to remove an item if is URL I go to Configuration form and I delete it.
But if I want to remove an item from a SPS Suite I must go to the "Get new apps", search in the list, ticked the app, push the button and confirm the uninstall.
This is very similar to the windows system for uninstall (go to the Control Panel, ...)
But ¿what is the uninstall system in IOS iPhone (Android is similar with the trash)?
I push over the app icon, it trembles and then I click on the x and the OS uninstalls it.
This is similar to the suggested feature:
-I put the pointer over the item in the context menu,
-I click the right button to place the focus of the new suggested "Action Modifier-Uninstall",
-I click with the left button over the item and SyMenu show me the uninstall confirmation window.
It's true that the diferent nature of the items complicate the reaction (only delete the item, uninstall if it is a SyMenu app, delete its contents if it is a container, etc) but, for the "lazy" users of our days, this is a problem that the program has to detect and ask  .
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
28/01/2018
|
I'm going to try cover the diferente reaction of the new feature over the diferent SyMenu Items:
• SySeparator or SyLabel: Not selectable elements.
• SyWebLink: Ask for Delete the SyMenu item.
• SyDocument: Ask for Delete the SyMenu item (¿Ask for delete the document too? Perhaps for a second version)
• SyFolderLink: Ask for Delete the SyMenu item (¿Ask for delete the folder too? Perhaps for a second version)
• SyWinCommand: Ask for Delete the SyMenu item.
• SyProgram : Two posibilities:
__a) The SyProgram item points to a SPS Suite program (path to SPSSuite folder): Ask for UnInstall the SPSSuite APP (shows the "Remove program" window. The same that you get as windows child uninstalling in "Get new apps")
__b) The SyProgram item points to NOT SPS Suite program (out of the path to SPSSuite folder): Ask for Delete the SyMenu item.
• SyContainer: Ask for two posibilities:
__a) Delete only the SyContainer item and put all the contained items in the parent folder.
__b) Run recursive over all the the the contained items (with the same scheme as above)
I think that this advanced feature allows a fast manage (cleaning) of the SyMenu items in the SyMenu user context, very in the line of "A normal user adds, updates and removes items only from the get new apps form", in the future the newbies could use SyMenu in this maner:
a) Search in the "Get new apps" form the needed APP.
b) Set SyMenu in automatic update mode.
c) UnInstall the App over the SyMenu (easier, fast and intuitive that search in the list of "Get new app". Even now I see that nothing saids that the uninstall procedure is go to "get new app" select a "Added" app and push the "Apply all" button)
Even, in the future, can be added "Drag and Drop" feature over the "Action Modifier" and the newbies will not need the configuration form for a basic configuration of SyMenu.
¿what to you think, Gian? ¿It's hard to code it?
.
edited by VVV_Easy_Symenu on 28/01/2018
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
29/01/2018
|
It's not hard to code, it's inconsistent.
The action modifiers are born with others purposes in mind, so I'm a bit reluctant to add a delete/uninstall feature. It's a modification feature and action modifier is not suitable for that.
Plus, as we have already seen, the delete/uninstall is an inconsistent action in itself, because it has so many different consequences according to the item you are dealing with.
One inconsistency in a planned feature makes me ring the alarm bell, think about what are ringing in my mind in this exact moment that we have two
Anyway I agree with you that going to the configuration form/SPS Manager only to remove an item is boring and since SyMenu is not a boring dog, let's think to another solution.
Since we can't use the action modifier (well I don't want to use the action modifiers... it's different), the most obvious way would be to use the right click.
In the Windows world the right click is something magical, you can use it to do anything you can't do in other way (the right one, the left click).
Unfortunately the right click in SyMenu is already taken. SyMenu uses the right click as a cycler for the action modifier. And I don't want to change such a consolidated function.
At this point our mouse has become useless and for this reason, the natural subsidiary, is the keyboard.
We already use the keyboard in the contextual menu.
We can select an item, execute an item, cycle the action modifiers (CTRL), change the search mode (F3), use the cursor keys to move the selection, use the letter keys as a shortcut to the items, hide the menu (ESC), show the menu (CTRL+F1). Probably the only thing we can't do with the keyboard is to pin the menu... and it's not intentional, because I love using the keyboard instead of the mouse.
So my proposal here is to implement the delete/uninstall as a feature only available through the keyboard.
The magic key could be the DEL one (CANC in my Italian keyboard but it's not a relevant topic here).
Implementing the feature in this way, leaves it hidden from normal users but, since I'm not granted that a normal user doesn't accidentally press the DEL key, I strongly prefer, for a while, to implement it in an experimental way to check for your feedback. So you will probably have to activate this feature in the options form before using it. And I have to be sure of your intentions so prepare to be asked for a confirmation before every cancellation.
I fear for the consequences of this new feature because it's a destructive one and because it's the first time a configuration is directly possible from the contextual menu. But I agree with you when you tell me that it should be very convenient.
What do you think about it?
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
30/01/2018
|
Implement the delete/uninstall as a feature only available through the keyboard is a nice solution and activate this feature in the SyMenu advanced options is a normal security.
Eager of the arrival :-)
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
25/02/2018
|
Hello guys.
Read here please to have a completely new point of view regarding a way to delete an item from the contextual menu https://www.ugmfree.it/Forum/messages.aspx?TopicID=631&lastpage=1#post2127
My sensation toward this solution is very positive because it is consistant and opens new possibilities to expand the features directly available in the context menu.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
25/02/2018
|
A contextual menu is a very good solution.
|
|
|
link
|