Update UI layout code for use of SVG icons #6977

poire-z · 2020-12-11T09:00:58Z

Don't trust the icons' native sizes: replace scale_for_dpi=true with width = height= DGENERIC_ICON_SIZE, so all icons get the same (tunable) size - except in a few specific use cases.

I've put DGENERIC_ICON_SIZE = 50 (updated to 48) to provoke a reaction :) as we need to decide a value for this.

More context around #6937 (comment)

This change is

Frenzie · 2020-12-11T09:13:48Z

50 or 48 (144/3)? I'll take a look at what the size looks like later/tonight. On Fri Dec 11 2020 10:01:16 GMT+0100 (Central European Standard Time), poire-z wrote: Don't trust the icons' native sizes: replace scale_for_dpi=true with width = height= DGENERIC_ICON_SIZE, so all icons get the same (tunable) size - except in a few specific use cases. I've put DGENERIC_ICON_SIZE = 50 to provoke a reaction :) as we need to decide a value for this. More context around #6937 (comment) This change is You can view, comment on, or merge this pull request online at: #6977 Commit Summary Update UI layout code for use of SVG icons File Changes M .luacheckrc (1) M defaults.lua (3) M frontend/apps/filemanager/filemanager.lua (4) M frontend/apps/reader/modules/readertoc.lua (17) M frontend/apps/reader/modules/readerview.lua (4) M frontend/ui/rendertext.lua (6) M frontend/ui/widget/button.lua (6) M frontend/ui/widget/configdialog.lua (6) M frontend/ui/widget/confirmbox.lua (4) M frontend/ui/widget/container/alphacontainer.lua (8) M frontend/ui/widget/container/movablecontainer.lua (6) M frontend/ui/widget/iconbutton.lua (7) M frontend/ui/widget/imagewidget.lua (6) M frontend/ui/widget/infomessage.lua (9) M frontend/ui/widget/multiconfirmbox.lua (4) M frontend/ui/widget/touchmenu.lua (3) M spec/unit/defaults_spec.lua (16) Patch Links: https://github.com/koreader/koreader/pull/6977.patch https://github.com/koreader/koreader/pull/6977.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

…

-- Sent with the new, awesome Vivaldi mail client / browser. Download it at vivaldi.com.

johnbeard · 2020-12-11T15:03:40Z

I recommend 48 as that's 1) a standard icon size and 2) easier to scale up and down to other common sizes.

poire-z · 2020-12-11T15:19:07Z

easier to scale up and down to other common sizes.

Does that matter at this point ? It's the target size, so no scale up/down (unless scaleBySize would magically round things nicely with 48 as input?).
You could keep your source at 144px - or do you plan to resize them at 48 ?

johnbeard · 2020-12-11T15:30:05Z

You could keep your source at 144px - or do you plan to resize them at 48 ?

Well, if we're going to actually render at 48px, it makes more sense to edit the SVGs at that size because then they'll be sharper (4px at 144px rendered at 48px will always be anti-aliased and fuzzy, and any lines not on a multiple of 3 pixel grid will be fuzzy too).

Whether that's an issue depends on the device I think. On my Clara HD, it's pretty sharp anyway (might just be too small for my eyes). On the emulator (and Android maybe??) it's pretty fuzzy.

Plus, if we go to 48px and round up from 4/3 to 2px, then we get thicker lines.

NiLuJe · 2020-12-11T15:32:51Z

The issue here is that the 48 @poire-z is talking about is not the 48px @johnbeard is talking about ^^.

That 48 is fed through scaleBySize, which will then spit out an actual pixel value, which will most likely never ever be 48px ;).

johnbeard · 2020-12-11T15:36:38Z

Oh right, I though it was going to change to be actually 48px (or some other value). Ignore me then, it doesn't matter what the SVG size is :-D

poire-z · 2020-12-11T15:37:28Z

Only on the emulator we'll render at 48px (may be only on my small one?). On my GloHD, I know my scale ratio: x 1.78667, so I'll have them at 85px.
(But I don't understand much about DPI and the scaling stuff, so I let you and @Frenzie take the right decisions :)

poire-z · 2020-12-11T15:43:14Z

(But but but... can I still get thicker lines ? :)

Frenzie · 2020-12-11T15:45:58Z

I don't think it's a relevant concern outside of computers with low-res monitors and very old devices, and it's not very bad on those either.

(But but but... can I still get thicker lines ? :)

Something like 6px at 144 or 2 at 48 is fine by me. However, I wouldn't worry too much about what it looks like at 48 unless that happens to be exactly the value we like. Worry more about how it looks at 96 or 144. ;-)

johnbeard · 2020-12-11T15:47:13Z

Are we talking thicker for all icons or just the appbar icons which render smaller (currently?)

Because if it's the latter, we should consider trying to figure out what the actual size ratio is so we can thicken those icons relative to the "normal" icons (e.g. zoom to page) so they come out at the same actual thickness on screen.

Frenzie · 2020-12-11T15:51:36Z

Pretty sure we're talking about all icons.

…

On Fri, Dec 11, 2020 at 4:47 PM John Beard ***@***.***> wrote: Are we talking thicker for *all* icons or just the appbar icons which render smaller (currently?) Because if it's the latter, we should consider trying to figure out what the actual size ratio is so we can thicken those icons relative to the "normal" icons (e.g. zoom to page) so they come out at the same actual thickness on screen. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6977 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRQBMLHNB7QLZOEYJDQX3SUI5JDANCNFSM4UWJYZZA> .

poire-z · 2020-12-11T15:52:50Z

which render smaller (currently?)

Smaller than what? Currently when ?
Because this PR is about making them all the same size: DGENERIC_ICON_SIZE (=48 currently).
(The zoom and direction one also, but these are allowed to have their size decreased to fit, only when needed.)

So, we all should test from now on with this PR applied on our emulator and devices.

NiLuJe · 2020-12-11T15:58:51Z

Assuming you've not set a custom UI DPI, the scaleBySize formula is:

ceil( input * ( ( min(viewWidth, viewHeight) / 600 ) + ( min(viewWidth, viewHeight) / 600 ) ) / 2 )

Or, if you've set a custom UI dpi and it doesn't match the device's:

ceil( input * ( ( min(viewWidth, viewHeight) / 600 ) + ( dpi / 160 ) ) / 2 )

On a H2O (1080x1429, 265 DPI):

~~echo $(( 48 * ( (1080/600.) + (265/160.) ) / 2. )) = 82.95px -> 83px~~
echo $(( 48 * ( (1080/600.) + (1080/600.) ) / 2. )) = 86.4px -> 87px

On a Forma (1440x1920, 300 DPI):

~~echo $(( 48 * ( (1440/600.) + (300/160.) ) / 2. )) = 102.6px -> 103px~~
echo $(( 48 * ( (1440/600.) + (1440/600.) ) / 2. )) = 115.20px -> 116px

EDIT: Fixed the maths xD.

EDIT²: Again.

NiLuJe · 2020-12-11T16:18:47Z

Now that I've stopped mangling the maths, the explanation: it was designed to be 1:1 on the original 6" Vizplex screens: 600x800 @ 167dpi.

(Especially compared to the 10.3" DX: 825x1200 @ 150dpi).

poire-z · 2020-12-11T16:36:06Z

Or, if you've set a custom UI dpi and it doesn't match the device's:

Is there a logic about this distinction ?
So, if I use the default of 300, or if I set a custom DPI of 301, I would get really different results ?

GloHD or ClaraHD (1448 x 1072 @ 300dpi):

> print( 48 * (1072/600 + 1072/600) / 2 ) -- with device dpi ("auto")
85.76
> print( 48 * (1072/600 + 301/160) / 2 ) - custom dpi of 301
88.03

> print( 48 * (1072/600 + 300/160) / 2 ) -- what we'd get with using device dpi of 300
87.88

NiLuJe · 2020-12-11T16:42:39Z

Or, if you've set a custom UI dpi and it doesn't match the device's:

Is there a logic about this distinction ?

I'm as puzzled as you are by that bit of logic every time I look at it ^^. (Which is why I almost always get it wrong each time I try to explain it ^^).

It possibly coulda maybe have made sense at the time, but it's certainly fishy nowadays.

NiLuJe · 2020-12-11T16:48:37Z

Rabbit hole:

The switch from 167 to 160 was explained by @Frenzie in simplify framebuffer dpi handling koreader-base#843
See also decouple reader setting from framebuffer koreader-base#822
And the original logic, from if there is custom screen dpi also scale by dpi koreader-base#344 was already roughly functioning the same way.

poire-z · 2020-12-11T16:49:21Z

So, I guess it's time to make it right, if we are going to resize things around a bit :)

NiLuJe · 2020-12-11T16:49:58Z

Let's see what @Frenzie has to say about it, but I'd tend to agree, yeah ;).

poire-z · 2020-12-11T17:09:11Z

There's a little top vs bottom menu bar height difference, because of this span:

koreader/frontend/ui/widget/touchmenu.lua

Line 236 in 86701f6

self.height = icon_height + Size.span.vertical_large

With:

Without:

So, we have to decide whether to kill that span at top, or add it at bottom.

Also, this PR does not include the line thichness reduction from #6937 (comment) .
That's another option to decide.

Frenzie · 2020-12-11T17:22:53Z

So, if I use the default of 300, or if I set a custom DPI of 301, I would get really different results ?

While quite unlikely for a minor step like the example given, it's certainly possible that all kinds of things could suddenly gain an extra pixel. Your 2px line turns into a 3px line at some point.

Setting aside the scaleBySize part of the equation:

1px at 160
turns into 2px at 240 DPI
1*240/160 = 1.5 → 2px
2px at 320
turns into 3px at… (and so forth)

So, I guess it's time to make it right, if we are going to resize things around a bit :)

Make what right, precisely?

Frenzie · 2020-12-11T17:24:21Z

Note that we purposefully play with the above. 0.5px at 160 = 1px, all the way up to far above 320 dpi. It then makes 160 DPI a bit fatter than the look we're actually going for.

Frenzie · 2020-12-11T17:27:00Z

Make what right, precisely?

Oh, I see what you mean. No, I think it's probably an oversight in custom DPI handling unless comments/git blame have anything pertinent to say.

Frenzie · 2020-12-11T17:28:37Z

Without:

Looks a bit unbalanced to me.

NiLuJe · 2020-12-11T17:29:42Z

So, we have to decide whether to kill that span at top, or add it at bottom.

I'd be moderately inclined to have it in both menus, but no super strong opinion about it (e.g., keeping the bottom menu as small as possible has its merits, although we are talking about a very few pixels here, so, eh ;p).

poire-z · 2020-12-11T22:25:10Z

There's a little top vs bottom menu bar height difference

OK, fixed. We can have both menu bars have balanced similar padding, here with Size.padding.default (that we can reduce if too much):

poire-z · 2020-12-11T23:58:51Z

I think, now with the sample blacker icons at 6px strokes, that I prefer our current smaller size of DGENERIC_ICON_SIZE = 40 to the 48 that I put to get larger and thicker icons and counteract their grayness.

(we just get them in the Zoom panel at 40, vs 50 before)

But as it's now configurable, one can have them to his taste. We just have to decide for a nice default.

Frenzie · 2020-12-12T09:43:08Z

Yup, let's just stick to the same old size. ;-)

poire-z · 2020-12-19T12:19:13Z

OK. Now other comment, can I merge it?

poire-z · 2020-12-19T12:20:37Z

Oups, some small cleanup in Makefile needed (I only rgrep'ed for stuff in subdirectories...).

Frenzie · 2020-12-19T12:21:49Z

Now other comment, can I merge it?

Actually I noticed you're also removing the source files for the old icons. Please don't! ^_^

Frenzie · 2020-12-19T12:23:07Z

I'd like to git mv them into an appropriate classic folder (and replace the seemingly random YAMLs by the relevant SVGs).

poire-z · 2020-12-19T12:28:12Z

Actually I noticed you're also removing the source files for the old icons. Please don't! ^_^

You really want me to let them?
(I've been just removing the exclusion from zip and rm of icons/src :)

git mv them into an appropriate classic

You'll have to rename a few of them to give them their new names.

Frenzie · 2020-12-19T12:35:27Z

You really want me to let them?

Yup! When I said PNG I meant PNG. :-)

poire-z · 2020-12-19T12:45:20Z

OK, done.

Frenzie · 2020-12-19T12:46:46Z

For example, here's what it looks like in GNOME Shell (I think the icon's drawn at ~ 300 × 300):

Frenzie

I didn't read/test the alpha stuff in detail but seems fine while skimming.

poire-z · 2020-12-19T12:58:21Z

Not much alpha stuff changed, but @NiLuJe will soon re tweak all that :)

@NiLuJe : one little useless thing to check anyway for your blit/alpha stuff changes: the alphacontainer, that is only used with PDF by readerview for its arrow - when Page overlap > Arrow is used instead of Gray out:

It's quite crappy, I remember I spent quite some time last week as the SVG stuff made it no more transparent. But well, rarely used, not important.

pazos · 2020-12-19T13:08:00Z

@poire-z: I tried to submit a PR against your branch but I cannot locate your fork as a base.

Anyway, it was to move platform specific resources outside shared icons:

diff --git a/Makefile b/Makefile
index 453757ef..17722647 100644
--- a/Makefile
+++ b/Makefile
@@ -383,7 +383,6 @@ androidupdate: all
 		-xr!*NOTES.txt$ \
 		-xr!*NOTICE$ \
 		-xr!*README.md$ \
-		-xr!*koreader.icns$ \
 		-xr'!.*'
 
 	# make the android APK
@@ -427,7 +426,7 @@ macosupdate: all
 		$(INSTALL_DIR)/bundle/Contents/MacOS \
 		$(INSTALL_DIR)/bundle/Contents/Resources
 
-	cp resources/koreader.icns $(INSTALL_DIR)/bundle/Contents/Resources/icon.icns
+	cp $(MACOS_DIR)koreader.icns $(INSTALL_DIR)/bundle/Contents/Resources/icon.icns
 	cp -LR $(INSTALL_DIR)/koreader $(INSTALL_DIR)/bundle/Contents
 	cp -pRv $(MACOS_DIR)/menu.xml $(INSTALL_DIR)/bundle/Contents/MainMenu.xib
 	ibtool --compile "$(INSTALL_DIR)/bundle/Contents/Resources/Base.lproj/MainMenu.nib" "$(INSTALL_DIR)/bundle/Contents/MainMenu.xib"
diff --git a/platform/mac/do_mac_bundle.sh b/platform/mac/do_mac_bundle.sh
index 02fcb400..933ab349 100755
--- a/platform/mac/do_mac_bundle.sh
+++ b/platform/mac/do_mac_bundle.sh
@@ -160,8 +160,7 @@ rm -rf cache clipboard history ota \
     l10n/.git l10n/.tx l10n/templates l10n/LICENSE l10n/Makefile l10n/README.md \
     plugins/SSH.koplugin plugins/hello.koplugin plugins/timesync.koplugin \
     plugins/autofrontlight.koplugin resources/fonts resources/icons/src \
-    resources/kobo-touch-probe.png resources/koreader.icns rocks/bin \
-    rocks/lib/luarocks screenshots spec tools
+    rocks/bin rocks/lib/luarocks screenshots spec tools
 
 # adjust reader.lua a bit.
 
diff --git a/resources/kobo-touch-probe.png b/resources/kobo-touch-probe.png
deleted file mode 100644
index d34260f7..00000000
Binary files a/resources/kobo-touch-probe.png and /dev/null differ
diff --git a/resources/koreader.icns b/resources/koreader.icns
deleted file mode 100644
index 97dd63f0..00000000
Binary files a/resources/koreader.icns and /dev/null differ
diff --git a/tools/kobo_touch_probe.lua b/tools/kobo_touch_probe.lua
index 7e2cf675..673ec778 100755
--- a/tools/kobo_touch_probe.lua
+++ b/tools/kobo_touch_probe.lua
@@ -51,7 +51,7 @@ function TouchProbe:init()
         },
     }
     self.image_widget = ImageWidget:new{
-        file = "resources/kobo-touch-probe.png",
+        file = "tools/kobo-touch-probe.png",
     }
     local screen_w, screen_h = Screen:getWidth(), Screen:getHeight()
     local img_w, img_h = self.image_widget:getSize().w, self.image_widget:getSize().h

poire-z · 2020-12-19T13:13:27Z

OK, I'm applying it, thanks.

poire-z · 2020-12-19T13:22:26Z

(Just changed your cp $(MACOS_DIR)koreader.icns to cp -pv $(MACOS_DIR)/koreader.icns - and renamed the files to their new locations.)

Also move Mac specific resource in platform/mac/.

poire-z · 2020-12-19T13:56:14Z

@NiLuJe : I haven't thought/I forgot about the inverted colors in nightmode:

I hope your yesterday patch takes care of that :)

Frenzie · 2020-12-19T15:02:45Z

@poire-z ~~Did you delete one too many?~~ False alarm, it came from a "private" plugin. (Nothing to it, just a quick investigation into a DB search interface.)

12/19/20-16:02:21 DEBUG cache image|resources/icons/dogear.png|23|23
./luajit: frontend/ui/widget/imagewidget.lua:191: attempt to index field 'bb' (a nil value)
stack traceback:
	frontend/ui/widget/imagewidget.lua:191: in function '_loadfile'
	frontend/ui/widget/imagewidget.lua:208: in function '_render'
	frontend/ui/widget/imagewidget.lua:313: in function 'getSize'
	plugins/coverbrowsersearch.koplugin/listmenu.lua:807: in function 'paintTo'
	frontend/ui/widget/verticalgroup.lua:48: in function 'paintTo'
	frontend/ui/widget/verticalgroup.lua:52: in function 'paintTo'
	frontend/ui/widget/overlapgroup.lua:82: in function 'paintTo'
	frontend/ui/widget/container/framecontainer.lua:96: in function 'paintTo'
	frontend/ui/widget/container/inputcontainer.lua:85: in function 'paintTo'
	frontend/ui/widget/verticalgroup.lua:48: in function 'paintTo'
	frontend/ui/widget/container/framecontainer.lua:96: in function 'paintTo'
	frontend/ui/widget/container/inputcontainer.lua:85: in function 'paintTo'
	frontend/ui/uimanager.lua:1089: in function '_repaint'
	frontend/ui/uimanager.lua:1235: in function 'handleInput'
	frontend/ui/uimanager.lua:1312: in function 'run'
	./reader.lua:306: in main chunk
	[C]: at 0x55fd5e4de791

NiLuJe · 2020-12-19T15:07:17Z

@poire-z: Nope, colors have to be inverted or the B&W stuff doesn't work ;).

(You'd need to single out actually color icons, don't composite 'em, and treat them almost like classic images, but not quite, i.e., with an extra invert in NM before blending. Which would then break highlighting for those ;). And needs a copy to not affect the cache).

poire-z · 2020-12-19T15:11:51Z

Did you delete one too many?

You probably did git pull and forgot to ./kodev something like build to have plugins/* copied into koreader-emulator/koreader/plugins/ (which happens to me quite often - and is a bit bothering when modifying plugins).

Frenzie · 2020-12-19T15:16:14Z

You probably did git pull and forgot to ./kodev something like build to have plugins/* copied into koreader-emulator/koreader/plugins/ (which happens to me quite often - and is a bit bothering when modifying plugins).

I always use ./kodev run (which does build) actually. It takes only a split second. :-) It's only for Android that I might avoid it. But it's a false alarm because it's just local due to the giant icon name/calling changes.

poire-z · 2020-12-20T13:12:57Z

frontend/ui/widget/iconwidget.lua

+
+-- Directories to look for icons by name, with any of the accepted suffixes
+local ICONS_DIRS = {}
+local user_icons_dir = DataStorage:getSettingsDir() .. "/icons"


I guess this should be DataStorage:getDataDir() instead of DataStorage:getSettingsDir().
(koreader/icons/ instead of koreader/settings/icons/)

Yes, it doesn't seem to have much to do with settings.

Should be `DataStorage:getDataDir()` instead of `DataStorage:getSettingsDir()`. (`koreader/icons/` instead of `koreader/settings/icons/`) #6977 (comment)

* Make sure scaleBySize *always* honors a DPI override, even if it's set to the native DPI... As discussed in koreader/koreader#6977 * Allow clearing a DPI override Useful when switching from a custom DPI to the native one. * Plug clearDPI into setDPI if it gets a nil (As that's what front does)

poire-z added this to the 2021.01 milestone Dec 11, 2020

poire-z mentioned this pull request Dec 11, 2020

Icon update using MaterialDesignLight #6937

Merged

poire-z force-pushed the icon_layout_tweaks_for_svg branch from 313f4ef to 03d5b1e Compare December 19, 2020 12:43

Frenzie approved these changes Dec 19, 2020

View reviewed changes

poire-z requested a review from pazos December 19, 2020 13:20

pazos approved these changes Dec 19, 2020

View reviewed changes

Remove PNG icons, add koreader.svg

8b348ee

Also move Mac specific resource in platform/mac/.

poire-z force-pushed the icon_layout_tweaks_for_svg branch from aef7e73 to 8b348ee Compare December 19, 2020 13:44

poire-z merged commit daefdc9 into koreader:master Dec 19, 2020

poire-z deleted the icon_layout_tweaks_for_svg branch December 19, 2020 13:49

NiLuJe mentioned this pull request Dec 19, 2020

Implement proper alpha-blending of SVG icons #7011

Merged

poire-z commented Dec 20, 2020

View reviewed changes

poire-z mentioned this pull request Dec 20, 2020

IconWidget: fix user icons directory path #7019

Merged

Frenzie pushed a commit that referenced this pull request Dec 20, 2020

IconWidget: fix user icons directory path (#7019)

9f25dc7

Should be `DataStorage:getDataDir()` instead of `DataStorage:getSettingsDir()`. (`koreader/icons/` instead of `koreader/settings/icons/`) #6977 (comment)

Update UI layout code for use of SVG icons #6977

Update UI layout code for use of SVG icons #6977

Conversation

poire-z commented Dec 11, 2020 • edited Loading

Frenzie commented Dec 11, 2020 via email

johnbeard commented Dec 11, 2020

poire-z commented Dec 11, 2020

johnbeard commented Dec 11, 2020

NiLuJe commented Dec 11, 2020

johnbeard commented Dec 11, 2020

poire-z commented Dec 11, 2020

poire-z commented Dec 11, 2020

Frenzie commented Dec 11, 2020

johnbeard commented Dec 11, 2020

Frenzie commented Dec 11, 2020 via email

poire-z commented Dec 11, 2020 • edited Loading

NiLuJe commented Dec 11, 2020 • edited Loading

NiLuJe commented Dec 11, 2020 • edited Loading

poire-z commented Dec 11, 2020

NiLuJe commented Dec 11, 2020 • edited Loading

NiLuJe commented Dec 11, 2020 • edited Loading

poire-z commented Dec 11, 2020

NiLuJe commented Dec 11, 2020

poire-z commented Dec 11, 2020

Frenzie commented Dec 11, 2020

Frenzie commented Dec 11, 2020

Frenzie commented Dec 11, 2020

Frenzie commented Dec 11, 2020

NiLuJe commented Dec 11, 2020 • edited Loading

poire-z commented Dec 11, 2020

poire-z commented Dec 11, 2020

Frenzie commented Dec 12, 2020

poire-z commented Dec 19, 2020

poire-z commented Dec 19, 2020

Frenzie commented Dec 19, 2020

Frenzie commented Dec 19, 2020

poire-z commented Dec 19, 2020 • edited Loading

Frenzie commented Dec 19, 2020

poire-z commented Dec 19, 2020

Frenzie commented Dec 19, 2020

Frenzie left a comment

Choose a reason for hiding this comment

poire-z commented Dec 19, 2020

pazos commented Dec 19, 2020

poire-z commented Dec 19, 2020

poire-z commented Dec 19, 2020

poire-z commented Dec 19, 2020

Frenzie commented Dec 19, 2020 • edited Loading

NiLuJe commented Dec 19, 2020 • edited Loading

poire-z commented Dec 19, 2020

Frenzie commented Dec 19, 2020

poire-z Dec 20, 2020

Choose a reason for hiding this comment

Frenzie Dec 20, 2020

Choose a reason for hiding this comment

poire-z commented Dec 11, 2020 •

edited

Loading

poire-z commented Dec 11, 2020 •

edited

Loading

NiLuJe commented Dec 11, 2020 •

edited

Loading

NiLuJe commented Dec 11, 2020 •

edited

Loading

NiLuJe commented Dec 11, 2020 •

edited

Loading

NiLuJe commented Dec 11, 2020 •

edited

Loading

NiLuJe commented Dec 11, 2020 •

edited

Loading

poire-z commented Dec 19, 2020 •

edited

Loading

Frenzie commented Dec 19, 2020 •

edited

Loading

NiLuJe commented Dec 19, 2020 •

edited

Loading