search

skyjake / lagrange

A Beautiful Gemini Client
https://gmi.skyjake.fi/lagrange/
BSD 2-Clause "Simplified" License
1.2k stars 62 forks source link

Add favicon capability #140

Open DrZingo opened 3 years ago

DrZingo commented 3 years ago

It would be nice if lagrange loaded /favicon.txt and presented it in the page top and bookmarks tab. There is a specification for it here: gemini://mozz.us/files/rfc_gemini_favicon.gmi

skyjake commented 3 years ago

I won't add an automatic favicon fetch because that goes against the design of Gemini IMO, but I suppose this could be a manual context menu item in the bookmarks list. It would then prevent the default behavior of a random icon being selected for that bookmark.

When adding a bookmark it could also provide a button for fetching the site favicon, if the user wants to check for one.

DrZingo commented 3 years ago

I understand, and I am myself a bit ambivalent about it. But as the icon is just one unicode character I think it suits gemini. Your suggested approach sounds good.

jamestomasino commented 3 years ago

I won't add an automatic favicon fetch because that goes against the design of Gemini IMO

This is very true. It's simple but it's a second request that's not user initiated. I don't think we have the same level of threat from it as http does with the favicon supercookies, but it is clearly a bolt-on that attempts to expand the spec. It should be aggressively fought against as default behavior.

DrZingo commented 3 years ago

Let the user decide, no icon, random icon (default and only choice now in Lagrange), or capsule icon. And why not implement it in a way so no redirects is allowed, only accept capsule:/favicon.txt I find the random icon quite annoying, as it changes the capsules intended view. Maybe I don't want a random chair/heart/toilet/hat as my logo on my capsule.

jpfox commented 3 years ago

A less automatic solution would be fine.

Maybe adding a button in bookmark edit dialog : [ Fetch favicon.txt ]. It will attempt to grab the /favicon.txt from capsule and replace old (or predefined) one.

Edit : realize it is exactly what you propose @skyjake :+1:

skyjake commented 3 years ago

f79e6735864a16c20d0ed0cc9d79c8c20aeb4816 puts you in full control of the bookmark/site icons.

And by this I mean that you get to manually set the icon to whatever Unicode character you want to use.

In light of recent discussions on the Gemini mailing list, it remains to be seen whether I'll add any further features to fetch server-defined icons. However, for now you will be able to do it manually by opening the gemini://some.site/favicon.txt and copypasting the character from there to the bookmark edit dialog.

IMO it is better to allow the user to choose which icon they want to use for a site, based on what meanings and connotations they ascribe to a particular symbol.

skyjake commented 3 years ago

A few more notes about supporting favicons.

This is a lot of complexity that is not really justified by the value added by server-provided favicons.

DrZingo commented 3 years ago

As there are objections overall to favicons, a context menu item in the bookmark list should be good enough, like "Fetch favicon". When it is clicked a redraw can be done. Cache seems overkill for gemini.

pitr commented 3 years ago

cache would still be needed as I understand it, as the favicon will be lost next time you reopen bookmarks sidebar or restart browser

DrZingo commented 3 years ago

cache would still be needed as I understand it, as the favicon will be lost next time you reopen bookmarks sidebar or restart browser

The favicon is stored in bookmarks.txt as a codepoint value.

skyjake commented 3 years ago

To clarify my previous comment, it was about implementing favcions the "web" way, where they would appear seamlessly without the user bookmarking anything. One can argue this is what a capsule owner expects to happen when they put up a favicon.txt.

Treating them as a suggested/default bookmark icon is quite a bit simpler to implement because a) Lagrange already supports customized bookmark icons (no additional caching needed), and b) the fetching can be done when requested or when the bookmark is created.

So my first comment pretty much still applies.

jazei-AR commented 3 years ago

but... ¿what is the risk of see the favicon in the address bar?

DrZingo commented 3 years ago

@jazei-AR: The risk should be no more than the gmi-request in the first place, as the URI would be hardcoded from the client. The reasoning against it seems to be more about that the gemini protocol is more or less "set in stone", and no fundamental altering should be done, and I think I agree to that.

marek22k commented 2 years ago

Hello,

I have a question about this: When I go to the page gemini://spartan.mozz.us/. Does the icon, which is in the favicon.txt, also appear with the page. What is the reason for this? spartan

Edit: Found the answer in https://github.com/skyjake/lagrange/blob/dev/src/gmdocument.c#L1918

skyjake commented 2 years ago

@marek22k Yes indeed, those are hardcoded icons for the sites that host a protocol specification. Lagrange does not check favicon.txt.

DidierMalenfant commented 1 year ago

f79e673 puts you in full control of the bookmark/site icons.

This seems to apply to bookmarks but how do sites like skyjake.fi/lagrange/ or gemini://gemini.circumlunar.space/capcom/ select the icon displayed in the title bar?

skyjake commented 12 months ago

The icon is chosen based on a hash of the domain name, so it is random but deterministic. Bookmark icons set by the user override the default icon. The official Gemini capsule has a hardcoded icon.

DidierMalenfant commented 11 months ago

Cool. That makes sense.

I assume the color scheme is also chosen in a similar way?

skyjake commented 11 months ago

That is correct. The various color schemes seed their random palette elements from the domain name (with a possible ~user path included), same as with the icon.

vg commented 6 months ago

The icon is chosen based on a hash of the domain name, so it is random but deterministic. Bookmark icons set by the user override the default icon. The official Gemini capsule has a hardcoded icon.

That is correct. The various color schemes seed their random palette elements from the domain name (with a possible ~user path included), same as with the icon.

Can you please share how this icon hash and color pallete is generated?

skyjake commented 6 months ago

@vg Well, you can find the code for doing that in gmdocument.c. The palette generation is not that straightforward because there are multiple theme variants. When it comes to the icon, the app computes a (slightly broken) CRC-32 of the domain name (possibly including a tilde username, like "domain.org/~username/") and picks the icon from a hardcoded set of Unicode characters. Various bits of the computed checksum are directly used when choosing theme colors.

zzo38 commented 5 months ago

My suggestion is, for one thing, allow an option to disable icons entirely, and allow the user to set icons (and colours) manually.

Many people (including myself) dislike the use of the /favicon.txt because it needs an extra request, which violates the principle of Gemini.

So, I have made up a way to use a X.509 certificate to define the favicon. Its working is: The ID of the extension is 2.25.327847519394146920218914781995694576662.3. The data type is a sequence. If the sequence contains a UTF-8 string then it is interpreted as specified in the specification of the favicon.txt. The implementation MUST allow the user to disable this feature, if it is implemented.

I personally don't like favicons and don't use it (and to me, I would be OK even if favicons are not implemented at all), but I made up such a specification only because of disliking the other method.

I think that #237 would also be acceptable (although only with the option that is disabled by default, as suggested by skyjake; or possibly with a button that will do so only if you explicitly select "download favicon"; or a combination of the two).