Shift dictionary to the bottom

[vjjustin]

Originally Posted by oren64

No, those patches are for devices when the top part of the screen is no more functional, so you can see the dictionary popup.

I am sorry, I wasn't clear enough. My intention is just to enlarge the dictionary popup size, not to move it down. The custom dictionary I use, has many definitions and examples that a definition usually has 10-15 pages. With a large popup this might get reduced. I don't mind the positioning.

Is there any way to do just this? In the dictionary frame size patch, how to set maximum height/width almost as big as the screen (750-800 out of 900(?) in GloHD)?

[jackie_w]

@vjjustin,

There are 2 dictionary patches in the current firmware:

1. patch_name = `Dictionary frame size - beta8`, in nickel.patch, which controls the size of the pop-up window. It aims to use as close to 50% of the screen as possible without completely obscuring the mini 3-icon pop-up (highlight/search/share) when the selected word is about halfway down the page. There is no attempt to permanently anchor the dictionary pop-up to either the top or the bottom of the screen
2. patch_name = `Dictionary text font-family/font-size/line-height - beta`, in libnickel.so.1.0.0.patch, which controls the appearance of the text within the pop-up

The firmware code which controls the dictionary pop-up changed a few firmwares ago. As you might guess from the 'beta8' part of the patch name of the first patch, it was 'a bit of a pig' to get it working at all after Kobo's firmware changes

However, if your aim is to make the dictionary window much bigger you don't really need the first patch at all. Once you select a word and get the initial pop-up just tap in a blank area somewhere inside the box and you'll get the (almost) fullscreen version of the dictionary definitions, and therefore less 'pages' to scroll through.

[vjjustin]

Originally Posted by jackie_w

patch_name = `Dictionary frame size - beta8`, aims to use as close to 50% of the screen as possible without completely obscuring the mini 3-icon pop-up (highlight/search/share)

Thanks, I understand the logic here. But I never use highlight/search/share menu. Dictionary on the other hand is very useful for me. Is it possible to make say 60-70%? Where in the patch has that 50% value (so that I can play around or is it an indirect approach and I cannot directly change values in the patch)?

Sorry if I am nagging.

you'll get the (almost) fullscreen version of the dictionary

Is it possible to make full screen view the default view when selecting a word (without the additional click)? Also, this seems to be taking more time to populate compared to the dictionary popup.

Originally Posted by oren64

I made two patches

2) dictionary frame always down, farm size more than 50% screen length.
* side effect the dictionary popup refresh.

I just tried this patch,the frame size is good size/feel better. But again the usecase is different, so (as intended) content still remain the same.

[jackie_w]

Originally Posted by vjjustin

Thanks, I understand the logic here. But I never use highlight/search/share menu. Dictionary on the other hand is very useful for me. Is it possible to make say 60-70%? Where in the patch has that 50% value (so that I can play around or is it an indirect approach and I cannot directly change values in the patch)?

The CSS which needs to be patched in the nickel file is stored in compressed (zlib) format. GeoffR's patching method does not currently allow us to make user-configurable patches for compressed CSS streams. However, if you have the technical skills and the necessary motivation to do your own experiments there are 2 other ways of creating patches which do allow you to modify compressed nickel code.

• pipcat method
• tshering's modifications for bad eyes

I haven't used tshering's method so I can't say anything about ease of use. I have used pipcat's method (plus GeoffR's makepatch utility) to convert pipcat-style nickel patches into GeoffR-style (non-user-configurable) nickel patches. Although I didn't find the pipcat method particularly difficult to learn it did take me a while to get my head around it. It's really up to you to decide how much time and effort you want to spend in creating your own personalised custom nickel patches. If you do decide to have a go the compressed CSS stream you need to patch is the one containing the variable named InlineDictionaryView but you will need to also make changes to other variables in the same CSS stream. Just a word of warning, the CSS stream number changes with every firmware update so you need to check that the work you already did is still valid each time.

Originally Posted by vjjustin

Is it possible to make full screen view the default view when selecting a word (without the additional click)?

If there is a way, I'm afraid I don't know of it.

[vjjustin]

Originally Posted by jackie_w

If you do decide to have a go the compressed CSS stream you need to patch is the one containing the variable named InlineDictionaryView but you will need to also make changes to other variables in the same CSS stream. Just a word of warning, the CSS stream number changes with every firmware update so you need to check that the work you already did is still valid each time.

Thank you, this works now. Very detailed instructions. I modified inlinedictionaryview, dictionary and textedit variables. I also modified margins/other settings. Is there any other variables I need to change?

There is a delicate balance between how/what can be changed without braking the code. And I don't exactly understand what each of these variable do or how to modify without breaking the code. Trial and error takes a lot of time. So, as you said may not be efficient to do this after every update. Any pointers welcome.

[jackie_w]

Originally Posted by vjjustin

I modified inlinedictionaryview, dictionary and textedit variables. I also modified margins/other settings. Is there any other variables I need to change?

If you've created a patch you're happy with there's no "need" to experiment any further - unless, of course, you're enjoying the experiments

My contribution to GeoffR's nickel.patch `Dictionary frame size - beta8` code includes changes to InlineDictionaryView, #dictionary, #textEdit, #header, #footer. I changed the last 2 to reduce the height of the dictionary pop-up header and footer. Kobo do l-o-v-e their large headers and footers

If you want it I can PM you a copy of the updated CSS stream I used to create it.

Originally Posted by vjjustin

There is a delicate balance between how/what can be changed without braking the code. And I don't exactly understand what each of these variable do or how to modify without breaking the code. Trial and error takes a lot of time.

I can't argue with any of that A user guide of variables/functionality would be very useful to patchers, but sadly will never happen.

Originally Posted by vjjustin

So, as you said may not be efficient to do this after every update. Any pointers welcome.

The amount of work involved each time the firmware changes depends on how you are applying your nickel patches.

1. If you use GeoffR's makepatch utility to convert each individual pipcat-style nickel patch into a GeoffR-style nickel patch (`Dictionary frame size - beta8` being just one example), then the nickel.patch code will survive a firmware update as long as Kobo didn't make changes to the contents of that particular CSS stream. The CSS stream number/location doesn't matter.
   
2. If you do all your nickel patches directly using the pipcat method then you have to revisit your patches for each new firmware. Even if the content of a CSS stream doesn't change, the CSS stream number/location (e.g. /* found: 80 (zlib) pos: 54f79e */) always changes.

Option 1 is better once all your nickel tweaked values are finalised. It's really the only option if you want to share individual patches with the typical non-techie MR member. The downside is it's not possible to let users customise the nickel patch with their own tweaked values.

Option 2 is much faster when you're experimenting, especially if you're changing a lot of different nickel CSS streams. You don't need to be nearly so careful maintaining the exact length of the original CSS code. Also, one of the major nickel CSS streams is so large that if you want to tweak it (which I do to change the look of the MyBooks list) it wouldn't be practical to convert it to a GeoffR-style patch.

You can't easily mix options 1 and 2, you need to pick one or the other.

[vjjustin]

Originally Posted by jackie_w

If you've created a patch you're happy with there's no "need" to experiment any further - unless, of course, you're enjoying the experiments

...the nickel.patch code will survive a firmware update...

Wow, that's great to know. I have the nickel.patch code. I do enjoy some basic experiments but only once every year or so

Originally Posted by jackie_w

Kobo do l-o-v-e their large headers and footers

If you want it I can PM you a copy of the updated CSS stream I used to create it.

That will really help me. I still need to make some tweaks. I was very close to asking you for help/modified.css, but then realized the fun is in doing it myself.

Also what is more interesting is they kept the min height and max height the same (or using only the min height). You would expect popup to be small when definition is small and large when definition is large. But when you set a smaller value for min height the popup remain small irrespective definition size. Don't know why the need for these two values.

Originally Posted by jackie_w

Option 2 is much faster when you're experimenting, especially if you're changing a lot of different nickel CSS streams. You don't need to be nearly so careful maintaining the exact length of the original CSS code.

I didn't check it. Now I think I should have tried it first. You are really helpful. Thank you and God bless you.