Genericizing?

[Xender]

Hi, it's me again ^ ^.

I think it would be nice to make this homepage generic, so that anyone could make own version by modifying something more friendly than separate HTML, CSS and some JS.

I was thinking about two approaches: templating or dynamically generating the page in JS. a) Templating - generating files from Mustache (or other) templates and user-supplied config in YAML/JSON. A proof-of-concept is on my fork - https://github.com/Xender/homepage/tree/OLD/static-templating. While not requiring big modifications to files, it requires user to re-run generation script each time config is modified (please see new section in README). Also, this is only a proof-of-concept, so if you were to approve it, please don't merge it into your tree by now. b) Dynamic generation - something like what https://github.com/mukyu/NeaterPage has - config.js file & adding elements to DOM in runtime. I think this is nicer, because doesn't require user to "recompile" page. But it would require some code rewriting.

I also plan on making script which would automatically download sites' favicons (and optionally turn them gray using ImageMagick). I don't see a way to do that dynamically, so it would also require recompiling.

Also introduction of light theme doubled most of the files. I think it would be nice to also genericize styles, so users could painlessly change colors and mascots.

Considering all of the above, please let me know, what do you think about genericing the homepage and whether the templated or dynamic would be better.

Thanks for reading such a long comment ^ ^.

EDIT: updated branch name from /templating/ to /static-templating-OLD/

[gokoururi]

b) Dynamic generation - something like what https://github.com/mukyu/NeaterPage has - config.js file & adding elements to DOM in runtime. I think this is nicer, because doesn't require user to "recompile" page. But it would require some code rewriting.

I would prefer this method. Recompiling the site would seem to require python. While most linux distributions are shipped with python out of the box, windows is not and would require manual installation. Its not difficult but inconvenient. Sudocracker seems to have done something along those lines in his fork

I also plan on making script which would automatically download sites' favicons (and optionally turn them gray using ImageMagick). I don't see a way to do that dynamically, so it would also require recompiling.

I'm not sure this would deliver acceptable results as the search icons aren't simply turned gray. The background is turned gray while the font is white. If we take the github favicon as an example, the now transparent part would have to be gray while the now black part would be white.

It would probably be easier to provide a default search icon for cases where a specific icon hasn't been made yet.

Also introduction of light theme doubled most of the files. I think it would be nice to also genericize styles, so users could painlessly change colors and mascots.

I plan on separating color settings into different css files to reduce redundancy. This would result in the following files:

• general.css
• dark.css
• light.css

Mascots remain a problem. Originally I had them defined in the stylesheet. Javascript would read the stylesheet and select a random mascot class. Unfortunately chromes javascript can't read stylesheets if the protocol is file://. Thats why I had to abandon this approach.

[Xender]

Ok, so here's a proof-of-concept of dynamic generation: https://github.com/Xender/homepage/tree/MESS-SUBJECT-TO-REBASE-dynamic-templating-poc Code is dirty. Styles are borked, because I forgot to rebase {camelCase to snake_caseprefix for replaceable classes} patch. But it works.

Will clean it up the day after tomorrow. ^ ^

[Xender]

Ok, dynamic generation done properly. https://github.com/Xender/homepage/tree/OLD/dynamic-templating

I've used Mustache.js after all, because I didn't find any feasible way to directly build DOM.

Mustache templates embedded in HTML as <script> with custom MIME.

Nuked style titles - as far as I understand, general.css should be persistent anyway - see https://developer.mozilla.org/en-US/docs/Correctly_Using_Titles_With_External_Stylesheets.

Decided to include theme style from script (by adding <link> to DOM), so it can also be persistent (only one will be loaded). I see this conflicts with approach you've taken in your master - d3aab1a66fe662e0bedac1d729d9e425e2a78746

I think that's it for dynamic generation, now I'd focus on fetching favicons.

Please let me know whether I should make Pull Requests of my changes (as they are or after some editing), or should the repos stay forked.

[gokoururi]

I'm considering merging it but its not working properly in chrome. $.getScript(theme_dir+"/mascots.js"); throws the following error:

XMLHttpRequest cannot load file:///C:/Users/XXX/Desktop/homepage-dynamic-templating/homepage-dynamic-templating/themes/dark/mascots.js?_=1400262298959. Received an invalid response. Origin 'null' is therefore not allowed access.

Everything else works after removing this bit and everything related to mascots.

[Xender]

Yeah, my friend has same problem. Looks like Webkit-related (same on Luakit).

Tried to work around it by appending <script src=...> to DOM (BUGFIX-chromium-getscript branch), but it's still the same. And it makes me wonder - it looks like Webkit is generating those requests on its own. Borked implementation of Same-Origin-Policy? ;_;

Anyway, will look for workaround.

[mouseroot]

Sounds like CORS issue, you cannot use XHR from the file:/// protocol hence why others use python to run a local server and bypass CORS alltogether.

[Xender]

@mouseroot - I didn't wanted to include Python as a dependency. But if I were to, then I'd just make script which generates HTML file without the dynamic config reading nor including additional Javascript in runtime using jQuery, so no CORS.

(Now a bit outdated) proof-od-concept static templating is here: https://github.com/Xender/homepage/tree/static-templating-OLD I think I may return to this approach.

[mouseroot]

I do agree that a project like this doesn't really need a dependency like python. a small work around could be jsonp assuming you could host your files on a remote server (perhaps github pages?)

that linked approach looks like it would be the most "user" friendly assuming your users are on linux (I myself am proudly on win7) so while it wont work out of the box its a lot easier then assuming your end user will just run a server

[gokoururi]

I don't want to complicate this stuff too much. My guess is most people will just use this repository as a reference for some html/css/javascript stuff anyway.

But I wouldn't mind putting a link to your ( @Xender ) repository into the readme if you added a simple description of how to get your stuff running (preferably on both linux and windows).

[Xender]

Hi, I'm not dead yet ^ ^.

So I've returned to this project and tried to look at the whole picture. I've made a roadmap for my fork. What you said about keeping this repo simple is totally logical.

Having said that, I've made some refactoring not related to templating, only to themes. I hope all those changes keep things simple enough - it's mainly shifting files around into some hopefully logical structure. I've made a PR - https://github.com/gokoururi/homepage/pull/4

I'd be thankful for a link in Readme, but first I'd like to refresh/refactor the generator and implement it also as a webapp.