You guys snuck this in quickly :)
will review/comment when i have some time

A few quick comments.
I was planning on making Dispatcher sortable but never got around to it, Thanks @hius07 for the implementation. I will probably steal it and integrate it directly into dispatcher.

I will state again for the record :) that i am against registering profiles in dispatcher as this can just lead to loops and generally should not be needed.
(I might also adapt onProfileShowMenu into Dispatcher)

I thought of removing automatic registration of the profiles. It would be done manually with a long-press on Execute or Show as QuickMenu (the check boxes should be added).
This would enforce the user to think about his use cases and would reduce the risk of loops.

I like the QuickMenus very much )) They are easy to use and save much time.

I tested this quickly and have some thoughts:

1. The ease of access to those profiles got improved tremendously! Thank you :) As a further improvement, can there be a new item in the Dispatcher called "Show list of profiles"? So that with one gesture the user can summon the whole list of profiles? With long-press activating them or showing their menu (to be consistent with the Profiles top menu) maybe.

2. There is option called "Copy". I think this better be named "Duplicate" since "Copy" implies (at least in my UX head) that it is going to be "Pasted" somewhere. However, there is no other place where this profile structure can be pasted.

3. When editing the actions of a profile, the same Dispatcher item list is used. This means that, for example, I can add the action "Execute Profile 2" in Profile 1 and "Execute Profile 1" in Profile 2. So this is going to be a loop. Haven't' tested this myself though. Shouldn't we better remove those profile-specific stuff from the profile actions editing list?

4. The old small nitpicks from my original Profiles: UX umprovement suggestions and tips #9391 (comment) are still there.

Again, thank you for your PR! KOReader rocks!

add these icons next to the "Execute" and "Show as QuickMenu" so the user will recognize them immediately.

Maybe, no strong opinion.

new item in the Dispatcher called "Show list of profiles"

Maybe. Short-press invokes profile QuickMenu, long-press executes the profile.

• When selecting some settings, like Font, Font weight, the menu with choices stays. However, since the these parameters are not applied right now, there is no point of staying here. So I think it is better to leave the menu once the choice is made. These are not the parameters where multiples things can be selected, right?

This is applicable not only to profiles, the submenu with checkboxes always remains open after checking/unchecking.
I agree that the submenu can be closed - when only one option can be selected and when the upper menu shows the selection in the menu item name. This improvement will require new property close_menu_after_check (default false) in the touchmenu widget.
Besides, the above checkboxes can be replaced with radio buttons (we've discussed this earlier).

No strong opinion either.
I was going to write: May be not this one - as it give a light feeling of misalignment:

but somehow, I like it - and it makes the 2 first items stand out as the ones that really do something.

The other may give a conflicting feeling with their following icons vs. our star and other following icons/indicators in other menus:

So, still no strong opinion :)

Besides, the above checkboxes can be replaced with radio buttons (we've discussed this earlier).

Don't remember what we may have concluded - but I would have probably say that our checkbox looks nicer than any radio button - and that checkbox were probably just fine in the menu, even if some of them act like radio buttons.

Don't remember what we may have concluded - but I would have probably say that our checkbox looks nicer than any radio button - and that checkbox were probably just fine in the menu, even if some of them act like radio buttons.

I remember you saying something to that effect, yeah ;).

No strong opinion on the icons thing either, FWIW, but if we like 'em, I do prefer it with them on the left, like @poire-z said ;).

What about closing the submenu with checkboxes after checking, when only one option can be selected?
Save one tap.

What about closing the submenu with checkboxes after checking, when only one option can be selected?

In the context of this PR: I don't mind.
Generically for all our menus, I do mind :) ie. in the font menu where we can select only one font: I don't want it to close, I may want to try another font. I think we may be fine with the current behaviour in other contexts too. But I guess it's in the context where it affects rendering, and you can witness the effect on the part of the book visible below the menu. I don't know if we should really have a different behaviour with menu items that don't have any visual effect. (Although I don't know, we already have keep_menu_open=true to have 2 kind of behaviours... :)

edit: but may be, if there's some visual indicator that is going to change state/place like checkboxes or radio buttons, we should keep showing it and its final state - as some user may otherwise want to re-enter that menu to be sure it applied. Unlike other menu that do launches something and you get some immediate feedback.

Regression:
This breaks dispatcher.
The Nothing option (and others) will not work with this PR.
Dispatcher is not designed to have other code store items in its data.
Creating a item.settings table and storing arbitrary stuff in it is going to break.
We need to find a different place for profile specific settings.

@hius07 : there is a little issue with how you implemented left alignment in Button, the tap area is smaller than the width (here, adding a bordersize to show it):

I guess because you wanted some left padding so the text is not stuck to the left of the framecontainer.

I guess this extra padding should be put/provided into the existing self.padding_h:

--- a/frontend/ui/widget/button.lua
+++ b/frontend/ui/widget/button.lua
@@ -84,6 +84,10 @@ function Button:init()

     local is_left_aligned = self.align == "left"
     local right_margin = is_left_aligned and (2 * Size.padding.large) or 0
+    right_margin = 0
+    if is_left_aligned then
+        self.padding_h = Size.padding.large
+    end

     if self.text then
         local max_width = self.max_width
@@ -153,7 +157,7 @@ function Button:init()
     if is_left_aligned then
         self.label_container = LeftContainer:new{
             dimen = Geom:new{
-                w = self.width - 4 * Size.padding.large,
+                w = self.width, -- - 4 * Size.padding.large,
                 h = widget_size.h
             },
             self.label_widget,

(without borders, fine with that? or would you prefer even more padding ?:)

Is your profile quickmenu the only current user of align=left ?
I wonder if we should have the "users" of left buttons provide padding_h=Size.padding.large, or if Button itself should hardcode (or add) it like I did above. (I guess for flexibility, it should be the users, as we may want to have no padding in some layout.

edit: or it should be some additional padding, as there, it seems to apply to the line separator - we may want it only inside the text button

There is something fishy about how Button handles its width.
I remember I fixed many widgets' width & padding & margin years ago, but I must have forgotten this one...

Currently, we provide a width or max_width, and padding/margins/border are then added to it.
Some widgets workaround that by computing some inner_button_width=my_required_width - my_padding, and provide width=inner_button_width and ensure margin and border=0.
Some don't, and just live with a larger width - and it seems we are ok with that when there is some centering and this goes unnoticed - or we get some extra padding/margin because the resulting container is bigger than the expected width, which could cause smaller line separators like in this screenshot (which could even be considered as looking nicer, but that's not what the code expected :) just a side effect of this "bug"):

Ideally, I guess Button should be fixed with this, if we want it to behave like most other widgets:

--- a/frontend/ui/widget/button.lua
+++ b/frontend/ui/widget/button.lua
@@ -82,12 +82,13 @@ function Button:init()
         self.padding_v = self.padding
     end

-    local is_left_aligned = self.align == "left"
-    local right_margin = is_left_aligned and (2 * Size.padding.large) or 0
+    local outer_pad_width = 2*self.padding_h + 2*self.margin + 2*self.bordersize

     if self.text then
-        local max_width = self.max_width
-            and self.max_width - 2*self.padding_h - 2*self.margin - 2*self.bordersize - right_margin or nil
+        local max_width = self.max_width or self.width
+        if max_width then
+            max_width = max_width - outer_pad_width
+        end
         self.label_widget = TextWidget:new{
             text = self.text,
             max_width = max_width,
@@ -146,14 +147,17 @@ function Button:init()
         }
     end
     local widget_size = self.label_widget:getSize()
-    if self.width == nil then
-        self.width = widget_size.w
+    local inner_width
+    if self.width then
+        inner_width = self.width - outer_pad_width
+    else
+        inner_width = widget_size.w
     end
     -- set FrameContainer content
-    if is_left_aligned then
+    if self.align == "left" then
         self.label_container = LeftContainer:new{
             dimen = Geom:new{
-                w = self.width - 4 * Size.padding.large,
+                w = inner_width,
                 h = widget_size.h
             },
             self.label_widget,
@@ -161,7 +165,7 @@ function Button:init()
     else
         self.label_container = CenterContainer:new{
             dimen = Geom:new{
-                w = self.width,
+                w = inner_width,
                 h = widget_size.h
             },
             self.label_widget,

but we may then have to fix a few other widgets (where the workaround was obvious), but for some when no expectation is obvious, they'll get bigger and may impact the existing layout and we'll have to notice it visually if things look odd.
Then, for the case in my previous post just above, ButtonTable could provide padding_h = 0 when centered (if we allow for the centered text to possibly reach the borders), and padding_h = Size.padding.large when left aligned, if we want some minimal indentation.

@hius07 : what do you think ?

Left-aligned button is used in VocabBuilder too.
I agree that reducing the size of the label_widget is incorrect.
If the correct fix of the Button breaks some other layouts, I do not think it is a big issue, the broken layouts will be fixed then.

Yeah, VocabBuilder is a festival of various kind of buttons :) @weijiuqiao : did you experience some odd stuff when you did build your layouts, like buttons becoming larger than your specified width and moving other things around? If we go with fixing this, I may request you to check and possibly adapt your VocabBuilder.

@hius07 : the problem is not mainly with your added support for left alignment, it was there before even when centered: buttons possibly ending larger than the specified width, and people usually fixing that in the upper widgets (so, it's fixed mostly everywhere it was needed - my dilemena is between making things clean everywhere and removing these fixes as they shouldn't be needed - vs. letting things be and adding more kludge to make it behave as expected :)

You know my point of view, I love cleaning everywhere.
It can be done step by step, while discovering/reporting broken places.

Update the patch to button.lua above, and with this in buttontable.lua:

+                padding_h = btn_entry.align == "left" and Size.padding.large or 0,
+                    -- allow text to take more of the horizontal space if centered

We would get this, with separator lines reaching the borders as when it is centered:

Very nice, I didn't like smaller separator lines.

Yeah, VocabBuilder is a festival of various kind of buttons :) @weijiuqiao : did you experience some odd stuff when you did build your layouts, like buttons becoming larger than your specified width and moving other things around?

I think I assumed everything was expected behavior as that was my first time meddling with KOReader's code :) I do remember having a bit of a hard time trying to put things where they are. It might be a mixture of my inexperience and the fishy button behavior?

If we go with fixing this, I may request you to check and possibly adapt your VocabBuilder.

It's okay, no worries.

Minor changes to vocabbuilder in the first commit of #10230 - hopefully it won't hurt.