fw 4.23.15505, MiniClock and NickelMenu

[jackiew1]

Not an issue it's just some musings after looking closer at changes to the GUI and nickel CSS:

There are a few parts of the new nickel CSS which could be patched to make minor cosmetic changes to the GUI, but most I've looked at wouldn't gain any real benefit.

One which might be worth pursuing is for the new Home screen clock. It should be easy to create a new patch which can

• change the size (for those who like the clock)
• make it invisible i.e. display white on white (for those who don't like it)

I'm waiting for some consolidated demand to emerge (or not) before taking it further. What I've seen so far on MR looks more like variations on "it's new, I need to complain about it".

[jackiew1]

@NiLuJe @pgaskin More musings re: Home screen clock vs. MiniClock.

There have been a few low-key MR rumblings about both clocks being displayed simultaneously. Personally I'm not sure it's within the scope of MiniClock to be worrying about this, but you might have other ideas.

However, there are some things to consider about interaction of MiniClock, NickelMenu and stock GUI. Aesthetics-wise it's getting difficult to find a single position to display MiniClock which doesn't interfere with something else in at least one other GUI screen.

• For example, my choice was bottom right corner but now that's in exactly the same place as the 'NickelMenu' button label. It's not NM's fault because without it the 'More' button label would be in the way. There isn't much wriggle room in that corner otherwise the MiniClock display and the in-book bottom progress bar overlap.

• Bottom left corner has a similar problem with the 'Home' button label.

• Top left corner would be OK if it wasn't for the fact that the new Home screen clock overwrites MiniClock every 60 seconds. It's fine once inside a book. It also wouldn't be a problem if MiniClock was only displaying HH:MM. Some users display more info than that.

[Aside: it's interesting that Kobo have decided to keep their clock permanently up-to-date rather than waiting for next page refresh. I wonder if that will impact battery life?]

• Top right corner has MiniClock and the in-book top menu clock/battery icon overlapping.

For now I've solved my own niggle by creating a personal quick & dirty patch to make all the new Nav button labels, including NM, invisible.

[NiLuJe]

Might be able to sandbox miniclock in the reader via nickeldbus (and a rewritten miniclock to go with it ;)), but in the meantime, there's not much the current implementation can do about it.

[pgaskin]

Top left corner would be OK if it wasn't for the fact that the new Home screen clock overwrites MiniClock every 60 seconds

It's really easy to patch out the auto-updates if you want.

[jackiew1]

Top left corner would be OK if it wasn't for the fact that the new Home screen clock overwrites MiniClock every 60 seconds

It's really easy to patch out the auto-updates if you want.

Not if it's only for me. Let's see whether there's any developing consensus about what other users want. Unless, of course, battery life does nosedive, in which case this patch would be very welcome.

I might be more interested in an extra option for NickelMenu which allows user configuration of the icon label (to null or spaces for my use case) rather than it always being "NickelMenu". If you do decide to add a custom icon then you could include your "branding" in the icon making a label less necessary. My current hacky patch will do for now. Even at my age I think I can remember what 5 icons do without needing labels. 😄

[pgaskin]

You should be able to style it by adding stuff to the MainNavButton qss (BTW, see my other post about Qt resources). To make this easier, I could add a custom Qt property to the NM button the same way as I already do for the old menu items. I'd prefer to avoid adding options to NM itself for styling the menu to give me the flexibility to make changes between minor versions and to do whatever is the easiest for the latest firmware version.

About the bottom nav, I was actually thinking of working on the opposite patch for myself: making it text only and more compact to increase cover sizes on the home screen and to increase padding (which was removed to make room for the scrollbar) in the library.

Slightly off topic: I'm currently looking into the request on MR about replacing the series book count with the series name. I think I'll be able to get it to work, but all the messing around with pointers, stack variables, and return values is somewhat annoying to deal with (I'm also busy this week, so I'm not spending too much time on it).

[jackiew1]

You should be able to style it by adding stuff to the MainNavButton qss (BTW, see my other post about Qt resources). To make this easier, I could add a custom Qt property to the NM button the same way as I already do for the old menu items. I'd prefer to avoid adding options to NM itself for styling the menu to give me the flexibility to make changes between minor versions and to do whatever is the easiest for the latest firmware version.

Perhaps I wasn't clear, patching MainNavButton qss is what I've already done to style all 5 Navbutton labels as white-on-white. My suggestion was to be able to change the actual text content of only the NM Navbutton label, e.g "NickelMenu" --> " ". This would leave the labels of the other 4 standard Navbuttons intact.

If user-configurable NM button label text is too much work then, for my own purposes and if it's safe, I'd be happy with manually hacking my own copy of libnm.so in a hex editor to change the NM button label text in there. Is that a possibility?

Incidentally I also tried patching MainNavView.qss (not zlib) to change the height of the whole bottom Navbutton container. It wasn't possible to change it enough to achieve what I wanted. At least not without adversely affecting the rest of the page.

About the bottom nav, I was actually thinking of working on the opposite patch for myself: making it text only and more compact to increase cover sizes on the home screen and to increase padding (which was removed to make room for the scrollbar) in the library.

Increase padding where? I'll be happy to test this on my various Kobos if you decide to pursue it.

Slightly off topic: I'm currently looking into the request on MR about replacing the series book count with the series name. I think I'll be able to get it to work, but all the messing around with pointers, stack variables, and return values is somewhat annoying to deal with (I'm also busy this week, so I'm not spending too much time on it).

I think this might be quite popular. I can imagine some users wanting to see both Series name and book count, rather than having to choose one or the other. You can count me in for testing this, too.

[jackiew1]

If user-configurable NM button label text is too much work then, for my own purposes and if it's safe, I'd be happy with manually hacking my own copy of libnm.so in a hex editor to change the NM button label text in there. Is that a possibility?

@pgaskin Actually I think I've answered my own question. I was able to find the "NickelMenu" string at 0x000ce10 of libnm.so (v0.3.2).

After manually overwriting it with spaces I've got what I wanted, i.e. the NickelMenu button no longer has a visible label and MiniClock can use that area at bottom right. The rest of the Navbuttons are labeled as per Kobo default.

[shermp]

Might be able to sandbox miniclock in the reader via nickeldbus (and a rewritten miniclock to go with it ;)), but in the meantime, there's not much the current implementation can do about it.

Just a note on this, I don't know enough about how reading works to know if we can (easily) detect when in the (a) reading view or not.

[pgaskin]

@jackiew1: pgaskin/NickelMenu@8ada23e16d3cb13bd2b9bd5585666e062dd3b353 (KoboRoot.tgz), experimental:menu_main_15505_label:<label>.

[jackiew1]

@pgaskin Been offline for a couple of days.

Did you want me to test this? If so, based on that menu item above, does the Kobo need to be running fw 4.23.15505? Most of my devices are running 4.23.15548. I don't want to brick anything.

Also how would I set it to blank or spaces?

[pgaskin]

Did you want me to test this?

If you want (I've already tested it).

I don't want to brick anything.

All NM options won't cause issues on 4.6+.

Also how would I set it to blank or spaces?

Just leave it with an empty trailing colon.

[jackiew1]

Just leave it with an empty trailing colon.

Ah, OK, thanks. I thought that might cause an error.

[jackiew1]

Well that seems to do the trick nicely. Thanks very much. 😃

I tried setting it to both blank and non-blank and yes I did need to reboot after the 2nd change.