NickelMenu: An integrated launcher for Kobo eReaders

[Elektron]

Originally Posted by LyrasDeamon

...


I keep getting config errors and can't quite see what I've done wrong.

...

What are the config error messages? And what firmware are you running?

[trcm]

nickle_misc ?

[geek1011]

Originally Posted by Ceiyne

I mainly use selection-based stuff in NickelMenu, e.g., custom searches for the words I have selected. I was wondering if there was a way to access other variables/parameters, such as the title of the current book?

That's planned for a future version. I just need to figure out a reasonably cross-version way to do it.

EDIT: Follow-up question, is there a way to create another sub-menu for selected text, or is selection_search the only option?

That's currently the only option, but I might allow this in the future. I haven't decided yet, though.

[Elektron]

Originally Posted by trcm

nickle_misc ?

LyrasDeamon made the typo in the post, but *not* in the config.

[gogu1904]

Hello,

Just a thought. Is it possible to have a NM menu option to do the KOReader update in one shot? I.E. start KOReader, do the update (incl open wifi), do the KOReader restart to end the update, then exit KOReader. Ultimately, I believe that a cloned starting script including all the goodies can be done. Of course, it is not a big thing. Before starting to play with this, are there any thoughts about difficulties on the way, or thoughts why this might be a bad idea?

Thank you!

[NiLuJe]

@gogu1904: You'll have to reinvent the wheel, because KOReader's OTAManager is tied into the KOReader UI.

So, basically, hardcode a mirror, hardcode a path to the latest zsync file you care about, download it, parse it to get the filename of the latest tarball, download said tarball, unpack said tarball, then classic handoff to the startup script.

TL;DR: Feasible, but, err, why? .

[Ceiyne]

Is there a way that I could set up a nickel_browser call to deal with this (minor) issue I'm having?

I currently have a search_selection menu item that uses nickel_browser to open an online dictionary URL. Everything works fine and the page opens correctly, showing the entries for the text I had selected.

The minor issue is: The page's "search" text box is focused automatically when the page opens, so since text entry is expected, the Kobo onscreen keyboard pops up. This covers half the screen, so every time I use this search I need to manually close the keyboard to view the results.

I know NickelMenu lets you use css to style the page, but as far as I know, there's no way to change the focused field using only css. Is there any other way I could avoid having the keyboard pop up?

I didn't try it, but I thought that hiding the search text field on the page with css might do the trick (because if the field isn't there, it shouldn't be able to receive focus, and the keyboard shouldn't pop up). Even if I'm able to do that, and it works, it's not an ideal solution because sometimes I will need to use that field to enter a new word to search for.

In case it helps, here's an example of the page I'm using. The encoded bit at the end is where I have the search parameter in my NickelMenu config.

https://jisho.org/search/%E9%A3%9F%E3%81%B9%E3%82%8B

[geek1011]

Originally Posted by Ceiyne

I didn't try it, but I thought that hiding the search text field on the page with css might do the trick (because if the field isn't there, it shouldn't be able to receive focus, and the keyboard shouldn't pop up). Even if I'm able to do that, and it works, it's not an ideal solution because sometimes I will need to use that field to enter a new word to search for.

Try hiding it, then using a CSS animation to show it later. That might work if the focus is done using JavaScript.

[Ceiyne]

Originally Posted by geek1011

Try hiding it, then using a CSS animation to show it later. That might work if the focus is done using JavaScript.

That's a good idea, thanks.

[criscros]

Quick question about the experimental option to replace the icon. I'm getting this error.

parse config files:file /mnt/onboard/.adds/nm/icon.png: line 1 field 1: unknown type '?PNG' (src/config.c:327)(src/config.c:936)

The icon.png is in the right folder, but is there maybe a size limit or should it be an .ico?

Thanks!

Also, what is the difference between the icon and icon_active?

[criscros]

Originally Posted by criscros

Quick question about the experimental option to replace the icon. I'm getting this error.

parse config files:file /mnt/onboard/.adds/nm/icon.png: line 1 field 1: unknown type '?PNG' (src/config.c:327)(src/config.c:936)

The icon.png is in the right folder, but is there maybe a size limit or should it be an .ico?

Thanks!

Also, what is the difference between the icon and icon_active?

Oops, sorry, just saw Semwize's post that it had to go in the icon folder.
Working now!

[-stepan-]

Hello. Sorry for my bad english - this is a Google translate. Sorry if I read this forum thread inattentively. Is it possible to invert and tap zones when inverting the screen in portrait mode? When reading in a case, the screen turns over, and it becomes inconvenient to turn page with left hand without setting tap zone manually. With the patch, flipping forward with both tap zones is ok, but I often have double clicks, but I don't like swiping - it's no my choice for Kobo Mini

[geek1011]

Originally Posted by -stepan-

Hello. Sorry for my bad english - this is a Google translate. Sorry if I read this forum thread inattentively. Is it possible to invert and tap zones when inverting the screen in portrait mode? When reading in a case, the screen turns over, and it becomes inconvenient to turn page with left hand without setting tap zone manually. With the patch, flipping forward with both tap zones is ok, but I often have double clicks, but I don't like swiping - it's no my choice for Kobo Mini

If you don't care about going backwards by tapping, my "Both page turn sides go next" libnickel patch could work. If you just want to always invert it, it should be possible to adapt the patch (I can do it when I have time, or @Semwize or @sherman might be interested in figuring it out). If you want it dependent on the screen orientation, I'd need to write a new patch for it.

[-stepan-]

Originally Posted by geek1011

If you don't care about going backwards by tapping, my "Both page turn sides go next" libnickel patch could work. If you just want to always invert it, it should be possible to adapt the patch (I can do it when I have time, or @Semwize or @sherman might be interested in figuring it out). If you want it dependent on the screen orientation, I'd need to write a new patch for it.

1. Yes, "Both page turn sides go next" libnickel patch working good, but I often have double tap, and go to the previous page only with a swipe.

2. I probably wrote it wrong before. In fact, I would like that when choosing an item in Nickelmenu "Invert screen orientation" (menu_item :reader :Invert Orientation :nickel_orientation :invert), when the book was turned over, the original tap zones themselves where were they.

In other words, my right and center is page forward in normal orientation when i read with my right hand. When I use an item "Invert screen orientation" from NickelMenu, when I flip the book in cover to my left hand, I want the left side of the screen and the center to be "forward" now. If this is currently impossible by a simple way in NickelMenu config, then you should not specially make patches for this - this is just my "wishlist", others probably do not need it. It's all about reading in the cover and use one hand for turn page - right or left hand without manually setup tap zones.

But a patch with the possibility of customizable tap zones in nickel reader would be very cool

[geek1011]

In other words, my right and center is page forward in normal orientation when i read with my right hand. When I use an item "Invert screen orientation" from NickelMenu, when I flip the book in cover to my left hand, I want the left side of the screen and the center to be "forward" now. If this is currently impossible by a simple way in NickelMenu config, then you should not specially make patches for this - this is just my "wishlist", others probably do not need it. It's all about reading in the cover and use one hand for turn page - right or left hand without manually setup tap zones.

I guess I could write an action to replace the code for prev/next dynamically. It would be simple, but I won't include it as an official feature since it'll be firmware-specific and a bit out of scope.

But a patch with the possibility of customizable tap zones in nickel reader would be very cool

It'd definitely be quite cool, and it would be a fun challenge to devise a good technique for live-patching it. I think I remember @sherman asking about this a while back too. I might try it at some point.