Added server example themes support with two sample themes and a favicon.

[jboero]

I've always thought the --path flag could be used to support basic UI themes and also thought it should have a favicon. I've added these and tested them out. Have a look.

[jboero]

Fixed whitespace

[jboero]

[jboero]

Ugh an issue with the build environment seems to be killing these Actions.

ModuleNotFoundError: No module named 'distutils'
https://github.com/ggerganov/llama.cpp/actions/runs/8859670654/job/24329697021#step:7:116

[jboero]

I think an update to our Actions environment is actually blocking these. Anybody else hitting this error?
#6422

[jboero]

@ggerganov did something change in testing automation? This PR is purely additive and shouldn't break anything else but automation keeps tripping on the same error as this python 3.12 support issue.

#6422

[ggerganov]

I think you need to rebase on latest master - there were some changes to the CI that are missing in this PR as it is

Btw, it seems the themes are copy-pasting the .js/.html code. Can this be avoided?
Otherwise, making a change to the frontend would have to be replicated across all themes - does not sound OK

[jboero]

Good point I'll try rebasing.

Otherwise, making a change to the frontend would have to be replicated across all themes - does not sound OK

I thought about symlinks for unchanged files but then there is the opposite problem. Changing one theme affects and/or breaks the other themes. I thought these were copied examples. What would you propose? This is simple just using the --path arg.

[jboero]

@ggerganov any bump on this? Since the UI is effectively rendered completely using the contents of the public folder it makes sense to me to change copies for themes and just use --path ./theme_dir

[ggerganov]

Let's give this a try, but first remove the following files from the themes:

• index.js
• completion.js
• json-schema-to-grammar.mjs

Since these are unchanged, they will be served from the static contents embedded in the server app:

llama.cpp/examples/server/server.cpp

Lines 3729 to 3735 in 947d3ad

	// using embedded static files
	svr->Get("/", handle_static_file(index_html, index_html_len, "text/html; charset=utf-8"));
	svr->Get("/index.js", handle_static_file(index_js, index_js_len, "text/javascript; charset=utf-8"));
	svr->Get("/completion.js", handle_static_file(completion_js, completion_js_len, "text/javascript; charset=utf-8"));
	svr->Get("/json-schema-to-grammar.mjs", handle_static_file(
	json_schema_to_grammar_mjs, json_schema_to_grammar_mjs_len, "text/javascript; charset=utf-8"));

Also rename all files that have underscore to use a dash for consistency

[jboero]

I see. I thought the path dir was all or nothing but yes that makes sense. OK let me clean it up a bit.

[jboero]

Sloppy commits but done. Thanks @ggerganov

[scottstirling]

How are folks gonna customize browser presentation code buried in the C++ binary? Or is the point to hinder that?

Every tweak to the UI will require a make to compile reload and test, defeating the utility & practicality of externalized user interface code.

[jboero]

Every tweak to the UI will require a make to compile reload and test, defeating the utility & practicality of externalized user interface code.

By separating the UI elements (--path [UIDIR]) and having the UI simply map to the API I don't think there is much to worry about. The static strings that become defaults in the C++ can simply be overridden by placing your file in the --path directory at runtime. Simple but effective actually or am I misunderstanding your predicament? This is how the binary has been built for quite a while.

[scottstirling]

Thanks for the clarification. I will pull the change and give it a try.