Reorganize "more plugins" submenu

[mwoz123]

• KOReader version: git mater
• Device: all

Issue

Extracted oftopics from :
#6101

"do we still need "more plugins" as there's something like "next page" in menu if there're too many entries?

Imho it's misleading."

"I guess the more_plugins menu isn't really needed anymore, now that the user can disable the plugins he doesn't need.
If you put some in more_plugins, no matter the user cleaning, he would have to tap once more to reach that unfortunate plugin we put into more_plugins.
If we'd want to keep more_plugins, only non-user-action plugins (those with only settings or some permanent behaviour) should go in there.
So, I wouldn't mind an initial Plugins menu with 20 items :) as I can clean it up to the 5 that matters to me., "
Source : #6101

Steps to reproduce

Open menu plugins although there's kind of" next page " functionality there's also" more plugins "

.

[Frenzie]

Simply doing what I wrote in #5461 (comment) is a thing one could do, but I changed the title because I don't want that to be presupposed to be the solution.

[hius07]

I would suggest the Plugins menu just simple:

Plugin management
-separator-
all activated plugins in alphabetical order

Allowing reorder the plugins list is the next step (and has no great sense imho).

[Frenzie]

I should clarify the menu vision. The More plugins menu is vestigial in its current form, the name perhaps most of all. As @mwoz123 said, it's misleading. For the sake of thinking about order it should be regarded as Miscellaneous tools or More tools. It looks like neglecting to change that name may well be the biggest mistake in this minor bit of laziness. ;-)

More tools is a submenu in the tools menu, not in the plugins menu. That everything in there happens to be plugins is merely a technical detail and not considered part of the unifying menu vision. Plugin management should be last as it is because it's only used once in a blue moon, if it should be in the tools menu at all. The same applies to settings more broadly. Putting plugin management in the tools menu is traditional, however.

Plugins should not and are not supposed to be most at home in the tools menu. Those plugins that happen to be in the tools menu are by and large there because that's where they fit best. Those that don't are new and I didn't have the heart or energy to make much of a fuzz about it provided they had a reasonable claim to the tools menu. That includes plugins like tweak document settings which should be more at home in settings → document.

The only sense in which the technical fact that these are plugins potentially conflict with the menu vision is that there are some fairly logical categories. Network/sync tools, device tools, document tools like reading statistics. But since you can and maybe will disable plugins, logical ordering without submenus may not be as problematic as it would otherwise be.

[yparitcher]

More tools is a submenu in the tools menu, not in the plugins menu.

I have been using koreader for a year and never realized it was a tools menu 😄
I always thought it was a plugin menu that happened to be called tools because history.
TIL

[Frenzie]

It's exactly the other way around. ^_^ Historically it was the plugins menu, which is an underlying technical detail that shouldn't normally form a part of user-facing UI/UX logic. A user just wants to perform an action, while knowing whether that action is implemented as part of the core or as a plugin is not something the user should have to know nor have to worry about. A menu location that only makes sense if you know how the action is implemented is not a good one.

The reason I created the MenuSorter module was in part motivated by this problem: how to get these plugins where they logically belong, rather than in the plugins menu. The main motivation was to be able to reorganize the menus easily without large code reorganizations and hacks. I've been very satisfied with the results since, but I'm not always as vigilant as perhaps I should be with regard to guarding against programmers following their natural instinct of letting implementation logic shine through in UI/UX.

In any case the tools menu fell by the wayside as a mental todo item after moving over those plugins that didn't qualify as tools over to more appropriate locations. But only because the remaining issues with it were so minor. It only needs a little bit of reordering and a few more separators, and possibly a couple of extra extractions to more appropriate locations.

[hius07]

Well, I forgot that Tools menus in reading and in FM differ.