status bar

[Commodore64user]

since @poire-z and @Frenzie think it would be a good idea to discuss changes in menus first, I propose, following #11549 to re-organise the status bar... next?. Any thoughts? I haven't actually consider the final layout so have nothing to show yet but would love to know if it would be welcomed or not.

The only thing I have done so far is group all the "items" into their own setting (which incidentally I would like to rename to complications, like in horology, but for reading) but I have a problem...
How do I turn this:

koreader/frontend/apps/reader/modules/readerfooter.lua

Lines 1973 to 1975 in fbd3e82

	if Device:hasBattery() then
	table.insert(sub_items, getMinibarOption("battery"))
	end

into something like this, or anything that works:

table.insert(sub_items, {
    text = _("Complications"),
    sub_item_table = {
        ... blah blah blah
        getMinibarOption("pages_left"),
        {
            if Device:hasBattery() then
                text = _("Battery Percentage"),
                checked_func = function()
                    return 
                end,
                callback = function()
                    getMinibarOption("battery")
                end,
            end
        },
        ... blah blah blah

[pazos]

The status bar is a manageable mess. The key concept to keep it manageable and thus maintained is to prevent new "complications" and encourage users to freely patch their own status bar with their own userpatches. New features should be quarantined for a while and get upstreamed after a careful consideration of usefulness vs spaguetti code ratio :)

Just my two cents

[Frenzie]

into something like this, or anything that works:

I rather suspect someone purposefully refactored it from something like that into what it is to make it easier to read. ;-)

That being said I don't really understand the question since you already give the answer yourself.

[Commodore64user]

That being said I don't really understand the question since you already give the answer yourself.

that snippet doesn’t work, which why I am asking for help getting to work.

it is a rather feeble argument to say that the menus look like an alphabet soup because it is slightly easier to read some code, i do hope that is not what you’re all hinting.

[Frenzie]

It might be helped by some separators though.

[Commodore64user]

Is that a firm 'No' on that idea?

[Frenzie]

Yes, submenus are a necessary evil but there doesn't really seem to be any reason to introduce them here.

[Commodore64user]

Come on, you can't say that. The reason is to decondense the menu, don't make it sound like there is no merit to the idea. Having said that, I understand your reasoning here, you want someone to be able to easily try all of them and then make a decision.

Thing is, some of these are the same with a minor technical difference so, makes sense to have them grouped under a submenu. Submenus are not evil, when used properly, bloated menus are.

I am of the believe that making a decision out of n-1 options is always easier than out of n options.

[Frenzie]

I believe that clicking/tapping more is almost always harder, even more so on ereaders.

But to be absolutely clear, my proposed alternative looks like this, not like nothing:

diff --git a/frontend/apps/filemanager/filemanagermenu.lua b/frontend/apps/filemanager/filemanagermenu.lua
index c6bb18d40..673e3bd1f 100644
--- a/frontend/apps/filemanager/filemanagermenu.lua
+++ b/frontend/apps/filemanager/filemanagermenu.lua
@@ -869,6 +869,7 @@ function FileManagerMenu:getSortingMenuTable()
                 self.ui.file_chooser:clearSortingCache()
                 self.ui.file_chooser:refreshPath()
             end,
+            separator = v.separator,
         })
     end
     table.sort(sub_item_table, function(a, b) return a.menu_order < b.menu_order end)
diff --git a/frontend/ui/widget/filechooser.lua b/frontend/ui/widget/filechooser.lua
index 8e00347dc..7748cfec4 100644
--- a/frontend/ui/widget/filechooser.lua
+++ b/frontend/ui/widget/filechooser.lua
@@ -96,7 +96,8 @@ local FileChooser = Menu:extend{
                 return function(a, b)
                     return natsort(a.text, b.text)
                 end, cache
-            end
+            end,
+            separator = true,
         },
         access = {
             text = _("last read date"),
@@ -149,6 +150,7 @@ local FileChooser = Menu:extend{
             item_func = function(item)
                 item.suffix = util.getFileNameSuffix(item.text)
             end,
+            separator = true,
         },
         percent_unopened_first = {
             text = _("percent - unopened first"),

[pazos]

it is a rather feeble argument to say that the menus look like an alphabet soup because it is slightly easier to read some code, i do hope that is not what you’re all hinting.

Quite the contrary, the alphabet soup is caused by a bunch of proudly contributors implementing what they want to extend the program :)
And it is quite hard to say nope to a new extension if it looks ok, works fine and has a purpose for somebody.

After years we figured out the best thing to do is set a scope, reject new features that are not deemed useful (or require a bunch of work for what is worth) and encourage further hacking using patches and plugins.

It is a good thing that you want to improve the "alphabet soup". That improvement requires a disccusion*. What you want to change in the status bar menus?

• New features that do nasty stuff with statusbar groups and placement don't belong to that discussion.

[Commodore64user]

Basically, make the whole menu more 'user friendly'. I don't intend to add anything new.

Right now there are settings strewn all over the place, I just want to go and make the place neat, sort of like spring cleaning. only without throwing anything out.

Particularly with the status bar, I see it needs changes in wording (for example there is a reference to an alternate status bar and that should be alternative instead, as alternate means: in turns, and alternative means: another option, among others) and putting existing settings in some order that makes sense.

Again, I created a PR for the screensaver which is currently open, where nothing in terms of features changed, just made it neatly organised.

[pazos]

Yup, I've got sidetracked by OP, which has nothing to do with wording or sorting or nesting :)

for example there is a reference to an alternate status bar and that should be alternative instead, as alternate means: in turns, and alternative means: another option, among others

Alternative isn't a good name to define what is it: "CREngine status bar that's limited and cannot be tweaked in the UI, doesn't work on PDFs and nobody here wants to maintain :p)

Alternate isn't also a good name, but at least has being sitting there unchanged for a while. No hard opinion on this one :)

As for the changed you want to propose I would suggest to make a PR, with simple sorting and naming changes and no extra code changes, and make a nice screenshot to make other people aware how it would look.

[poire-z]

(which incidentally I would like to rename to complications, like in horology, but for reading)

No issue with reorganizing stuff.
But some issue with wanting to use complications :) It won't read easy for people who did not go to Oxford, so I'm afraid our English UI can't really be "fancy/précieux" English, and needs to stay "simple" English. (I use the English UI just because the strings are shorter than French and technical stuff just reads better in English - and I would stop on "Complications" and wouldn't dare going into it to get more complicated options :)).

Also, there's some mixed wording styles: I can somehow guess who among us wrote a menu item :) (I must have worded 30% to 50% of our menu items). There are some from others that I still find odd (ie. Reclaim bar height from bottom margin) but somehow, their wording made sense for the people who made the feature (I'm not sure how I would rewrite this one - and I'm curious how you would, and I think you may not manage to make it clearer).
So, I don't know what you can manage to do, but I fear (like with the Screensaver menu) that when trying to make some consistent and poetic, you may lose some clarity that the current clumsy wording may bring).
Just some thoughts, not stopping you :)

[Frenzie]

do it like

[NiLuJe]

Yup, I essentially use it like an on-demand status pane, so it's setup to take a relatively generous amount of space when it is actually displayed.

So even if I didn't already abhor wasted space anyway, losing that bottom region 99.99% of the time would feel pretty stupid ;).

[NiLuJe]

(It's also mildly useful when attempting to work around various ReaderZoom madness when I feel masochistic enough to try to deal with it on fixed layout documents).

[NiLuJe]

Not a fan of superimpose for that, and while overlay always kind of implies some kind of transparency/blending to me, it is at least somewhat closer to what actually happens, so, eeeeh, could work, maybe.

I definitely agree that the current wording is fairly technical and rather unhelpful unless you've already groked how the hell we actually layout a Reader page, which is not necessarily a given, even for actual contributors ;o).

[Frenzie]

I think overlay is better.

[Commodore64user]

since the sleep screen was finally merged (yay!) I will start working on the status bar then. As soon as there is anything to show for, I will update you. Peace!

unless there are objections...