kobopatch - An improved patching system - Page 10

jackie_w · 07-17-2018, 12:37 PM

Quote:

Originally Posted by jcn363

Could we pass the device as a parameter or use a variable?

Spoiler:

I've got 4 different models which I'm still patching every fw update. That sounds like I'd need 4 different configurations instead of the single one I currently have. It sounds like more work.

jcn363 · 07-17-2018, 01:15 PM

Quote:

Originally Posted by jackie_w

I've got 4 different models which I'm still patching every fw update. That sounds like I'd need 4 different configurations instead of the single one I currently have. It sounds like more work.

I realy prefer to make a device dedicated one versus worldwide one.

It depends on the patch and/or the value of parameter/variable. If you pass a number of devices as parameter the patch will made for those devices. If you don't pass a parameter (or var is null) the program acts as now.

This could be a comparative

Spoiler:

In the first case (now) the user must go patch by patch changing the value he/she wants. In the second one he/she only must say the device once.
I think it's pretty simple for the common user.

Good luck.

Terisa de morgan · 07-17-2018, 01:43 PM

Nobody should write after a nap....

boriar · 07-17-2018, 02:20 PM

Like I see, I think is better the second option. With the first you still must modify the patch whenever you use for a different device going through the patch file to comment and uncomment options. With the second you must change only the name of device at the beginning.
But @geek1011, why not to pass the name for device like a parameter?

norbusan · 07-17-2018, 11:51 PM

Quote:

Originally Posted by geek1011

For overriding the in tag, it would be simple (just setting cfg.In). I would need to add pflag for command line parsing, so tell me before you make a PR, if you are planning to. I can do this myself if you want.

Do you prefer the external pflag or the golang internal flag library? Syntax-wise they seem to be rather close.

Adding some command line parsing I would switch to specifying the config yaml via an extra cmd line flag instead of a normal argument?

E.g.

Code:

  kobopatch [--config SomeConfig.yaml] [--firmware PathToFirmware.zip]

WDYT?

geek1011 · 07-18-2018, 09:48 AM

Quote:

Originally Posted by norbusan

Do you prefer the external pflag or the golang internal flag library? Syntax-wise they seem to be rather close.

Adding some command line parsing I would switch to specifying the config yaml via an extra cmd line flag instead of a normal argument?

E.g.

Code:

  kobopatch [--config SomeConfig.yaml] [--firmware PathToFirmware.zip]

WDYT?

I prefer pflag (spf13's fork), as it has better help, supports sort flags, and uses 2 dashes for long flags. Have a look at this to see how I usually implement flags in my apps.

I'd keep the config as a positional argument so Windows users can drag and drop a config file.

geek1011 · 07-18-2018, 09:52 AM

Quote:

Originally Posted by jcn363

I realy prefer to make a device dedicated one versus worldwide one.

It depends on the patch and/or the value of parameter/variable. If you pass a number of devices as parameter the patch will made for those devices. If you don't pass a parameter (or var is null) the program acts as now.

This could be a comparative

Spoiler:

In the first case (now) the user must go patch by patch changing the value he/she wants. In the second one he/she only must say the device once.
I think it's pretty simple for the common user.

Good luck.

Hmm. I'm not totally convinced this is a good idea. This would add a lot of parsing complexity, make patches less readable, and increase the change of mistakes and bugs. The only benefits would be shorter patches and less comments if I understand this correctly.

Also, did you get the quotes working properly?

jcn363 · 07-19-2018, 03:39 AM

Quote:

Originally Posted by geek1011

Hmm. I'm not totally convinced this is a good idea. This would add a lot of parsing complexity, make patches less readable, and increase the change of mistakes and bugs. The only benefits would be shorter patches and less comments if I understand this correctly.

Also, did you get the quotes working properly?

The last first.
I think so. Thanks. There was an extra " ' " hidden.

If you aren't convinced, then you shouldn't do.
Don't worry about. Your decision on the parameter/variable will be the best.
You had fill the main goal

(zlib support

).

Just in case this helps (I hope so):
I think is a question of choosing between an universal solution and optimized one.

In the first case final user must choose (one by one) all his/her devices need.
And very important: you have spare time, because you are done.

In the second one, user gets what his/her device needs in exchange of a device id, but must run once per device.
You must think on and code.

This reminds me... the code is not optimized at all (there is an entire css four times repeated) and we overload it with more (four or six options for one only device is a lot of dead code).

So, as a final user, what do you want? Do you prefer simplicity or universality?
And you developer?
Yours is the last word. Thanks.

Good luck.

jcn363 · 07-21-2018, 03:45 AM

Two typo on nickel 4.9.11311.

Spoiler:

Good luck.

geek1011 · 07-21-2018, 01:38 PM

Quote:

Originally Posted by jcn363

Two typo on nickel 4.9.11311.

Spoiler:

Good luck.

What patch is that? I don't remember converting a patch that looked like that.

Also, I'll be away for the next 2 weeks. I'll be unable to respond to any posts. If a new firmware version happens to come out during that time, GeoffR should be able to update and release a new version. If not, I'll do it as soon as I am back.

jcn363 · 07-21-2018, 01:54 PM

Quote:

Originally Posted by geek1011

What patch is that? I don't remember converting a patch that looked like that.

Also, I'll be away for the next 2 weeks. I'll be unable to respond to any posts. If a new firmware version happens to come out during that time, GeoffR should be able to update and release a new version. If not, I'll do it as soon as I am back.

It is new (I think).

Don't worry, be happy!

Good luck.

davidfor · 07-21-2018, 09:14 PM

Quote:

Originally Posted by jcn363

Two typo on nickel 4.9.11311.

Spoiler:

Good luck.

What does this change? When I first saw it, my thought was that it might be the cause of the missing top margin when opening an epub. But, I'm not sure if the name and sizes fit.

jcn363 · 07-22-2018, 10:46 AM

Quote:

Originally Posted by davidfor

What does this change? When I first saw it, my thought was that it might be the cause of the missing top margin when opening an epub. But, I'm not sure if the name and sizes fit.

I don't think so.
I'm not totally sure because it doesn't happen to my A1.

#48 involves only A1 but margin-right => no way, and
#138 involves only Aura and bottomVerticalSpacer min-height -> it is a good candidate but it must be tried on it.

Anyway, if it makes work a little bit better... it can't be bad.
Ref.
Good luck.

jcn363 · 07-23-2018, 09:44 AM

This kind of zlib optimization per device it's not very big (about 12% better in my A1), but, at least, it's not less than zero.
I must say I don't really noted any improve while I was reading but... numbers are numbers.
I've though this can be a kind of placebo, and that's because I'm uploading here, just in case someone wants to prove... Thanks.

Good luck.

Edit:
Here we go again.
Now with Dragon (AuraHD, H2O) version too.
If you try, please share your impressions.
Edit²:
Nova (ClaraHD) added. I can't test on the device, therefore the risk is all yours (as always).

Edit³:
Added clean file. Even better (at least, if you don't own several devices or use locale

). Without locale and device seems more responsive.

Note: is for A1.

Good luck.

jcn363 · 08-03-2018, 04:12 AM

I've added a new file, a clean one, in the previous post. Now yes, I can say I really noticed an improvement while I was reading.

Good luck.

07-17-2018, 01:43 PM	#138
Terisa de morgan Grand Sorcerer Posts: 6,233 Karma: 11768331 Join Date: Jun 2009 Location: Madrid, Spain Device: Kobo Clara/Aura One/Forma,XiaoMI 5, iPad, Huawei MediaPad, YotaPhone 2	Nobody should write after a nap.... Last edited by Terisa de morgan; 07-17-2018 at 02:40 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
kobopatch - A new (WIP) patching system	geek1011	Kobo Developer's Corner	93	05-27-2018 03:04 PM
Patching H2O	Maillemom	Kobo Developer's Corner	8	10-19-2016 09:58 AM
Instructions for patching firmware 3.17.3	GeoffR	Kobo Developer's Corner	60	09-17-2015 05:35 PM
Instructions for patching firmware 3.8.0	GeoffR	Kobo Developer's Corner	92	10-22-2014 07:22 AM
how to clean more disk space in root file system to upgrade system	chinaet	iRex	1	12-18-2006 03:54 PM

07-17-2018, 02:20 PM	#139
boriar Evangelist Posts: 407 Karma: 314204 Join Date: Jan 2015 Device: bq Avant XL, Kobo Aura H2O, Onyx Boox M96C Plus	Like I see, I think is better the second option. With the first you still must modify the patch whenever you use for a different device going through the patch file to comment and uncomment options. With the second you must change only the name of device at the beginning. But @geek1011, why not to pass the name for device like a parameter?

08-03-2018, 04:12 AM	#150
jcn363 absolute beginner Posts: 323 Karma: 1750999 Join Date: May 2017 Location: Go with the wind (43°19'17.7"N 2°00'19.4"W) Device: ka1	I've added a new file, a clean one, in the previous post. Now yes, I can say I really noticed an improvement while I was reading. Good luck.

Advert

Advert