Nickel Icons

[tshering]

Originally Posted by frostschutz

Sometimes you have the same picture but at differnet resolutions, so one of them is used by Kobo Glo, another by Kobo H2O, etc. The filenames might change with every firmware update too [they're byte offsets in the nickel file], so - it involves a bit of trial & error. There is no way to determine what's what automatically...

I did once a somehow similar project. There, I added dimensions and size to the file name. That made gassing a bit easier.

[frostschutz]

could do that, full screen images are the exception, though.

[tshering]

Originally Posted by frostschutz

could do that, full screen images are the exception, though.

Sure, I choose full screen images as examples since there the interpretation is rather obvious, but I found the dimensions in other cases also helpful.

[frostschutz]

Updated it to also work with GloHD/KA1 (same udev rule as my other mods).

[MGlitch]

I know you don't have a Forma to test on, but is there any reason to suspect this wouldn't work on one?

ps if I do install this I might have to start saying I have a Kobo Forma frostshutz edition

[frostschutz]

I haven't tested this mod in quite a long while. It depends on USB storage removal ( DEVPATH=="/module/g_file_storage", ACTION=="remove" ) to work so if that hasn't changed lately then you might be good to go.

Only one way to find out.

[MGlitch]

Good news/Bad news

Good news- it does extract the .png and I assume mng files (I haven't looked for them).

Bad news- I had no idea there were so many png/mng files nor that they were named so uselessly to humans. This is going to be a longer project than I thought.

[frostschutz]

yeah, sorry about that...

giving them sensible names... well, it wouldn't be entirely impossible, I guess, but it would require a human to give them those names in the first place (like a file with a huge list of checksum -> name). Or someone tell me if there are internal names that can somehow be extracted from the binary.

[tshering]

Originally Posted by frostschutz

yeah, sorry about that...

giving them sensible names... well, it wouldn't be entirely impossible, I guess, but it would require a human to give them those names in the first place (like a file with a huge list of checksum -> name). Or someone tell me if there are internal names that can somehow be extracted from the binary.

In libnickel.so.1.0.0 you can find a lot of image file names like :/images/search/magnify_glass_off.png. I do not have the necessary skills to automatize associating the names with the position of the streams in nickel.

[frostschutz]

These strings appear in what seems to be a string table of sorts, wide variety of strings thrown together randomly.

00d32cb0  62 6f 6f 6b 73 41 64 64  69 6e 67 00 41 64 64 69  |booksAdding.Addi|
00d32cc0  6e 67 3a 20 78 00 00 00  62 6f 6f 6b 73 52 65 6d  |ng: x...booksRem|
00d32cd0  6f 76 69 6e 67 00 00 00  52 65 6d 6f 76 69 6e 67  |oving...Removing|
00d32ce0  3a 20 79 00 64 6f 6e 65  42 75 74 74 6f 6e 00 00  |: y.doneButton..|
00d32cf0  3a 2f 69 6d 61 67 65 73  2f 73 65 61 72 63 68 2f  |:/images/search/|
00d32d00  6d 61 67 6e 69 66 79 5f  67 6c 61 73 73 5f 68 69  |magnify_glass_hi|
00d32d10  74 2e 70 6e 67 00 00 00  41 64 64 20 42 6f 6f 6b  |t.png...Add Book|
00d32d20  73 00 00 00 53 6f 72 74  3a 20 3c 69 3e 44 61 74  |s...Sort: <i>Dat|
00d32d30  65 20 41 64 64 65 64 3c  2f 69 3e 00 53 6f 72 74  |e Added</i>.Sort|

So it's not like it has offset addresses for me to pick up right then and there. Binary format is unfortunately not that simple. If it exists at all, the table that relates these is ... elsewhere ... I guess. It's probably beyond what I can script in the shell.

[tshering]

Originally Posted by frostschutz

So it's not like it has offset addresses for me to pick up right then and there. Binary format is unfortunately not that simple. If it exists at all, the table that relates these is ... elsewhere ... I guess. It's probably beyond what I can script in the shell.

I think there is no chance without using a disassembler anyway.

[Elektron]

LOL, the charge icon...

[geek1011]

Originally Posted by tshering

I think there is no chance without using a disassembler anyway.

The resources are stored as three static variables: qt_resource_data (all the files appended to each other), qt_resource_struct (the metadata for the resources), and qt_resource_name (the filenames). See https://code.woboq.org/qt5/qtbase/sr...c/rcc.cpp.html for the details. The hardest part is actually locating those variables, since they are static, but since they are predictable, there might be a way to do it without disassembling stuff and finding the call to the resource registration. I'll be looking into this soon, since I want to try some things with it for my own purposes.