Hey! On a non existent resource request, my Gemini server responds with the following:

51 \r\l

The Gemini protocol states, that

<STATUS><SPACE><META><CR><LF>

Status codes beginning with 5 are PERMANENT FAILURE status codes, meaning:

"The request has failed. There is no response body. The nature of the failure is permanent, i.e. identical future requests will reliably fail for the same reason. The contents of META may provide additional information on the failure, and should be displayed to human users. Automatic clients such as aggregators or indexing crawlers should not repeat this request."

As of my understanding, the META may be empty, so "51 \r\l" is a valid response. But Kristall shows the following error message:

Protocol Violation The server did not serve the content you requested in a well-defined manner and Kristall could not process the data sent. Line is too short for valid protocol

Just noticed that I can't use the extra buttons on my mouse to move backwards and forwards in the history, as I usually can in browsers. It would be a nice addition :)

Current URI: "http://example.com/somedirectory" Href attribute of clicked link: "somesite.html" URI kristall is trying to access: "http://example.com/somesite.html" Expected URI: "http://example.com/somedirectory/somesite.html"

Update: When the current URI has either a "/" or a filename at the end, it does seem to work. The current problem seems to be the name of the folder that does not end with a "/"

This PR adds a man page generation script. On Linux man pages are considered the go-to help resource by many, so I feel it's a good idea to create one

Currently, the script looks at the gemtext about:help document, and converts it to the man roff format. A 'head' and 'tail' are also added with manpage-specific things (flags, etc) in them.

I've opened this as a draft as there is mostly likely stuff that will have to be changed before actually merging this.

Things to consider:

• Currently, the script strips out the first and last 7 lines of the about:help document which don't really belong in the man page. I think there is a better approach to handling this.
• Not yet added to a make target, so it doesn't get generated automatically yet
• We need to work out where to actually store the man page when running make install. Might be /usr/share/man/man1?

Suggestions are appreciated!

Hi! Build is going well until it tries to install icons.

On my system, /usr/share/icons/hicolor/ and subdirectories do not exist. The simple workaround is obviously to create

share/icons/hicolor/scalable/apps share/icons/hicolor/16x16/apps share/icons/hicolor/32x32/apps share/icons/hicolor/64x64/apps share/icons/hicolor/128x128/apps share/applications

But if those could be created in the makefile it would maybe help others.

Thanks!

I am trying to install Kristall on MacOS/Catalina, but the instructions are pretty cryptic:

"Use the Makefile to build build/kristall instead of the default target. There is currently no auto-recognition of MacOS (where qmake will output a kristall.app file), so you have to be a bit more manual."

I cloned the Kristall repo and know how to edit Makefile. I also installed qt5 and qt-editor via Homebrew. But now I am stuck - apparently I need to install "widgets and network modules," which I have no idea how to do, while it isn't at all clear how I have to edit the Makefile.

Is this app only for experienced qt users? If not, I'd be grateful for some more helpful instructions.

I'm using the OS Default theme and the black icons can be hard to see depending on the area:

An option to switch icons to a white variant for dark theme users would help.

Hello, I'm unable to build 0.3 on Ubuntu 20.02. I get the following error message:

$ cat /etc/os-release                                                                                                                   2 ↵
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
$ make
mkdir -p build
cd build && qmake ../src/kristall.pro && make 
make[1]: Entering directory 'xxx/kristall-0.3/build'
g++ -c -pipe -Wno-unused-parameter -Werror=return-type -std=c++17 -O2 -std=gnu++1z -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_MULTIMEDIAWIDGETS_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I../src -I. -I../lib/luis-l-gist -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtSvg -isystem /usr/include/x86_64-linux-gnu/qt5/QtMultimediaWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o abouthandler.o ../src/abouthandler.cpp
In file included from ../src/ssltrust.hpp:9:0,
                 from ../src/kristall.hpp:9,
                 from ../src/abouthandler.cpp:2:
../src/trustedhostcollection.hpp:7:20: fatal error: optional: No such file or directory
compilation terminated.
make[1]: *** [Makefile:960: abouthandler.o] Error 1
make[1]: Leaving directory 'xxx/kristall-0.3/build'
make: *** [Makefile:20: build/kristall] Error 2
$

Any idea what I might be missing? Thanks in advance!

Getting this same error when trying both the release and master branch (Arch linux):

Bus error (core dumped)

Here's some info from the core dump:

master branch:

Stack trace of thread 2856621:
#0  0x00007f88d4f6774c gst_update_registry (libgstreamer-1.0.so.0 >
#1  0x00007f88d4efc0af n/a (libgstreamer-1.0.so.0 + 0x390af)
#2  0x00007f88d932a4c8 g_option_context_parse (libglib-2.0.so.0 + >
#3  0x00007f88d4ef38dd gst_init_check (libgstreamer-1.0.so.0 + 0x3>
#4  0x00007f88d4ef3985 gst_init (libgstreamer-1.0.so.0 + 0x30985)
#5  0x00007f88d509bec3 n/a (libgstmediaplayer.so + 0x8ec3)
#6  0x00007f88db11f06f n/a (libQt5Multimedia.so.5 + 0x5506f)
#7  0x00007f88db15d84e _ZN12QMediaPlayerC2EP7QObject6QFlagsINS_4Fl>
#8  0x0000564aa7bd9a33 n/a (/home/rjt/.local/bin/kristall/kristall>
#9  0x0000564aa7bb375a n/a (/home/rjt/.local/bin/kristall/kristall>

release

Stack trace of thread 2933655:
#0  0x00007f810016474c gst_update_registry (libgstreamer-1.0.so.0 + 0xa474c)
#1  0x00007f81000f90af n/a (libgstreamer-1.0.so.0 + 0x390af)
#2  0x00007f81041574c8 g_option_context_parse (libglib-2.0.so.0 + 0x604c8)
#3  0x00007f81000f08dd gst_init_check (libgstreamer-1.0.so.0 + 0x308dd)
#4  0x00007f81000f0985 gst_init (libgstreamer-1.0.so.0 + 0x30985)
#5  0x00007f810039eec3 n/a (libgstmediaplayer.so + 0x8ec3)
#6  0x00007f8105f4c06f n/a (libQt5Multimedia.so.5 + 0x5506f)
#7  0x00007f8105f8a84e _ZN12QMediaPlayerC2EP7QObject6QFlagsINS_4FlagEE (libQt5Mul
#8  0x000055f87c82f603 n/a (/home/rjt/.local/bin/kristall-0.3/kristall + 0x4d603)
#9  0x000055f87c80ec0f n/a (/home/rjt/.local/bin/kristall-0.3/kristall + 0x2cc0f)

almost identical

Let me know if there's any other info I could give you that might help.

I am using nightly Windows version, downloaded today (May 24th, version 0.4).

• Run kristall.exe
• Do some changes to favorites, like adding a link, creating/deleting a group, etc.
• Quit Kristall
• Run Kristall again
• Changes to favorites are not reflected.

But I expect Kristall to remember my favourites.

A workaround would be saving Settings (by clicking "OK" in Settings dialog). That saves favourites as well.

When server sends response: 30 /\r\n the browser should redirect to home page of the server but Kristall instead shows "Protocol Violation" page with error code "Line is too short for valid protocol".

I believe this response is valid one since status code 30 allows returning relative paths. Other Gemini browsers (for example Amfora) handle this response correctly.

One of my planned Gemini projects is to place the Berean Study Bible online both as a unified document and as each book split into different chapters where each will be a file. It takes an instant to load the entire 4Mb Berean Study Bible into NVIM and less than to seconds to load and display the same Bible in Lagrange. The timing of Kristal to load and display the Berean Study Bible is unacceptably long — see the attached screenshot.

The file being loaded is not online but on the local file system and loaded with the file:///path/to/file.gmi URL.

EDIT: I realise that optimisation is a process that should wait until other major goals are achieved first, but it will improve the user experience if an indicator is displayed that the file is being retrieved, perhaps a progress bar of some sort. At present nothing happens other than a garbled screen until Kristall has fully loaded the file. The first time(s) this happened, I assumed Kristall had crashed, which was not the case since the screen was restored once loaded.

I have elevate this to a new issue after replying to this mentioned in a different issue.

@przsak can you test if the icons are now visible?

On Ubuntu 20.04 using QT + i3 Window Manager, I cloned the current kristall repo from github today and issued a make command as a regular user which created a kristall binary. The missing or not displayed icon issue remains the same with all the icons to the left of the URL bar not being displayed while those on the right side of the URL are displayed. I feel the position of the icons might be relevant to the issue.

This same issue persists in an appimage nightly build I found somewhere on the Internet.

Could it also be related to a missing icon or system font on the system?

EDIT: There also appears to be icons missing in the menu under the view option where three blank boxes appear next to Document Outline, Favourites and History.

Interestingly, on my QT-based desktop, having the Kristall menu open inhibits screenshots being made using Flameshot though this is rectified the moment I close the drop-down menu. This affects both clicking on the Flameshot icon on the i3 toolbar or when pressing the PrtScreen key which has been mapped within the i3 conf to a Flameshot capture command. This sort of behaviour where one app influences or inhibits the operation of another should not exist on Linux systems.

Originally posted by @casperl in https://github.com/MasterQ32/kristall/issues/64#issuecomment-1250074838

I'm playing around with Gemini a bit and have created a small server. This redirects the user from "" to "/". However, the message "Protocol Violation: Line is too short for valid protocol" appears. I compiled Kristell myself with the code from https://github.com/MasterQ32/kristall/releases/tag/V0.3 . I have seen that there is already such a bug (https://github.com/MasterQ32/kristall/issues/199). I'm a little confused because I should be using the latest version with the latest release, right?

the second to last sentence in section 3.3 of the spec says

If is an empty string, the MIME type MUST default to "text/gemini; charset=utf-8".

currently kristall is interpreting it as "/" and giving an error.

"20\r\n" error afaict "20 \r\n" text/gemini; charset=utf-8

OS: macOS Montery terminal: kitty

if there's anyone out there like me who is having trouble building Kristall, despite having the latest openssl and qt5 installed with brew

here's the command I ran in the root folder that seemed to do the trick make build/kristall LFLAGS="-L/usr/local/opt/openssl@3/lib -stdlib=libc++ -headerpad_max_install_names $(EXPORT_ARCH_ARGS) -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=10.13 -Wl,-rpath,@executable_path/../Frameworks" export CXXFLAGS="-I/usr/local/opt/openssl@3/include -pipe -stdlib=libc++ -Wno-unused-parameter -Werror=return-type -std=c++17 -O2 -std=gnu++1z $(EXPORT_ARCH_ARGS) -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=10.13 -Wall -Wextra -fPIC" LDFLAGS="-L/usr/local/opt/openssl@3/lib" --debug

I'm not super well versed with the complications involved with editing makefiles and flag values, so providing everything upfront in the command just happened to work best for me.