# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 24
# self = https://watcher.sour.is/conv/xpvn34q
So, with the “-t” option, one do not longer have to recompile on theme changes (templates and CSS), correct? A simple yarnd restart does it, yes?
@fastidious no restart required in debug mode -D 👌
@fastidious no restart required in debug mode -D 👌
@prologic looks like templates changes are applying (after a restart), but not CSS changes.
To elaborate, yarn.min.css isn't recreated upon changes on the other CSS files.
@fastidious Why would it? Do you really expect yarnd to re-run an external tool minify here in production mode if you change the theme's CSS? 🤔 I _never_ expected this to be honest 😂 Run your pod in -D mode when doing theme dev 🤣
@fastidious Why would it? Do you really expect yarnd to re-run an external tool minify here in production mode if you change the theme's CSS? 🤔 I _never_ expected this to be honest 😂 Run your pod in -D mode when doing theme dev 🤣
@prologic right, I forgot the first—and so far only—wiki page, that deals with this specifically. All good now. I was thinking on a way to avoid having to run minify. There is an option, but running minify after a change on the CSS is not that big of a deal so, as I said, all good. 🙂
Personally I'd just make a non upstream wrapper script that runs minify after each build, or whatever, if I wanted to automate it. That's my solution to a lot of things 🤣
@eldersnake yes, I just have the minify command in a makefile, then run make on the CSS directory after any changes.
@eldersnake We’ll make dev basically does this 🤣 I guess my point is if you’re running a production instance then you really shouldn’t be modifying the theme 😁 at least not in this way ☺️
@eldersnake We’ll make dev basically does this 🤣 I guess my point is if you’re running a production instance then you really shouldn’t be modifying the theme 😁 at least not in this way ☺️
\n> if you’re running a production instance then you really shouldn’t be modifying the theme\n\nThen git pull and make is also out of the question? 😩😂
@fastidious Not what I meant 😂
@fastidious Not what I meant 😂
@prologic yeah but unless I'm missing something, a custom theme's CSS won't be minified like the default one is in the Makefile. And you discourage modifying the Makefile for obvious reasons, therefore the solution is either run minify manually or make a basic wrapper script if one doesn't want type out that command everytime 😅
What I mean is... When I make changes to any of the code, or the built-in theme, I do so on my local dev instance, test it, commit and push. Then I rebuild my production image (_I use Docker_) and redeploy 😂 I don't touch the production version -- In the case of a custom theme, I would _probably_ do the same, then package it up and send it over to the "server"(s). But I totally get that everyone will have different "workflows" 🤣
What I mean is... When I make changes to any of the code, or the built-in theme, I do so on my local dev instance, test it, commit and push. Then I rebuild my production image (_I use Docker_) and redeploy 😂 I don't touch the production version -- In the case of a custom theme, I would _probably_ do the same, then package it up and send it over to the "server"(s). But I totally get that everyone will have different "workflows" 🤣
@prologic \n> But I totally get that everyone will have different "workflows"\n\nOr none, like me. LOL. I am thinking on running Arrakis for good, so I need a systemd init script. I can come up with one, but if anyone has it already handy, I would take it!
@eldersnake LOL 😂 I _obviously_ don't discourage local mods or even mods to the Makefile1 per se, just as you rightly point out, the more local changes you made the harder it is to track upstream changes. Git merges are a bitch 🤣 Anyway... Am I missing something obviously here with how we _should_ handle custom themes or "theme packs" if you will? 🤔 I also have in the back of my mind that a theme could be a "ZIP" archive of some kind too. i.e: yarnd -t mytheme.zip.
@eldersnake LOL 😂 I _obviously_ don't discourage local mods or even mods to the Makefile1 per se, just as you rightly point out, the more local changes you made the harder it is to track upstream changes. Git merges are a bitch 🤣 Anyway... Am I missing something obviously here with how we _should_ handle custom themes or "theme packs" if you will? 🤔 I also have in the back of my mind that a theme could be a "ZIP" archive of some kind too. i.e: yarnd -t mytheme.zip.
@fastidious I've got one, if you're still in the market. 😁
Fat fingers. Meant this for (#tabrhxa) systemd convo.
@jlj \n> I've got one, if you're still in the market.\n\nSure thing, toss it over, please! I am being very lazy this weekend. Got a house to clean, and I am procrastinating like never before to do anything 🙈. So, yes, if you have a working systemd init, please share.