Jbut me personally, I wouldn't care as long as it works well
Jso like, whoever shows up first?
Blets be clear i cant write that me and javascript dont go together all that well
Bhonestly people should get over all the disgust with electron it doesnt make all that much sense
Jyeah I'm not picky on implementation because I just want to see if the model works. if it's a great idea people will put it in terminals, if not then we have this, I'm just tired of doing like console profiles and stuff
Bme too
Aime all web-based terminals add more latency than they should tbh but I've been using code-server at work as my main shell and it is mostly ok
Abut vs code doesn't support ligatures and it is still a less responsive than iterm2 
AKonsole is the best all around terminal I've found
AI just found the exact mechanism: It's not on app launch. Instead,
So if you wanna be sure a user has it for Flatpaks before updates, you can ensure that your yafti first boot runs:
flatpak updateSo if you wanna be sure a user has it for Flatpaks before updates, you can ensure that your yafti first boot runs:
PYeah, it'll also install it when you install a gnome flatpak (which is how I discovered it) with the system theme set.
ASurprisingly not.
ASo it seems to behave the same as nvidia/amd drivers: Installed on
flatpak updateOh maybe it's because you're installing things as system flatpaks? I definitely had it auto install the theme flatpak when I installed another flatpak
AExact same result if I do --user instead. No theme.
AActually, wow, even though I said "no" to installing it during
So I can't test the thing you're saying. ^^ It's glued in there now. So there's a good chance that you're right that it installs itself during
flatpak updateSo I can't test the thing you're saying. ^^ It's glued in there now. So there's a good chance that you're right that it installs itself during
flatpak install <something else> too.AYikes, dconf-editor as Flatpak was totally unusable. It was showing the wrong data (Flatpak environment's rather than the host's) and was unable to see the host environment at all. RIP to anyone who was using it:
https://github.com/flathub/ca.desrt.dconf-editor/pull/24
https://github.com/flathub/ca.desrt.dconf-editor/pull/26
Pretty amazing how those bugs escaped notice for 2111 days (first Flatpak release was on Aug 4, 2017).
https://github.com/flathub/ca.desrt.dconf-editor/pull/24
https://github.com/flathub/ca.desrt.dconf-editor/pull/26
Pretty amazing how those bugs escaped notice for 2111 days (first Flatpak release was on Aug 4, 2017).
AKind of an important tool for everyone building new defaults for immutable distros! 
A@hermmm and I are trying to figure out an appropriate name for a special branch on the
The layout will be:
-
-
We need a name for
Names that have been considered and rejected:
-
-
-
-
Uncertain names:
-
Leading names (clearest names so far):
-
-
startingpoint repo:The layout will be:
-
template: Untouched template branch, which comes from the startingpoint repo itself. People don't modify it. It's used for easy fast-forwarding / syncing of repos to update their local copy of the template.-
<something>: The ONLY branch that gets deployed (published) to GHCR. All other branches will merely build but won't deploy. This ensures total control over GHCR publishing.We need a name for
<something>.Names that have been considered and rejected:
-
deploy or deployment: Very accurate names but also very ugly word.-
public-
release: Too confusing since Releases are a GitHub feature.-
productionUncertain names:
-
customLeading names (clearest names so far):
-
publish-
live
XI like live, it's a noun but implies the same thing
AI agree, it's a neat name.
XOther one could be
prod being short for productionAMaybe, but still unclear. I definitely think
liveAgreed
AI would love to hear some other opinions to decide if we should settle on that name, think you'll be on in like 1-2 hours when we'll hopefully have heard someone else? Or should I just go for it and force-push new commits that switch to 
liveIt's a clear name, purpose is obvious, and it's not a verb so it doesn't sound weird in that way.
ASo depending on how you feel about it, I could have updated commits ready in 5 minutes.
XSure, but maybe read my other comment first. And excuse me for maybe not getting it.
ADidn't see it, reading now. Edit: I'll reply there to keep that discussion there.
Edit: I'll reply there to keep that discussion there.A@hermmm Okay the PR is updated and ready. Thanks for a good discussion, I really like the new name we came up with.
A@hermmm Sorry I didn't mean to click "disable auto-merge". Mistake. Let's re-enable it.
XRead my comment. Auto-merge is a new thing I think jorge turned on, and it requires the workflows to run. There's no other ways to merge.
AI am not sure. The repo's own existing workflow file should be the one that runs. It would be a literal exploit if I could submit a pull request where I change teh workflow to submit code to GHCR. I could literally make a PR to ublue-os/main that installs a virus if that were the case. 
So I dunno why it's not running the old workflow on the current PR! It should be running the old
Anyway, the changes are two things:
1. The publish to GHCR only happens if the branch is named
2. The auto-trigger workflows are changed to the following:
https://i.imgur.com/7EW7t9D.png
So I dunno why it's not running the old workflow on the current PR! It should be running the old
mainAnyway, the changes are two things:
1. The publish to GHCR only happens if the branch is named
live2. The auto-trigger workflows are changed to the following:
https://i.imgur.com/7EW7t9D.png
Imgur
XThe repo's own existing workflow file should be the one that runs. It would be a literal exploit if I could submit a pull request where I change teh workflow to submit code to GHCR.Hmm I wonder how PRs with changes to workflows are handled then...
AWhat this means is:
- Pull requests will only run builds when they target
- Cron schedule will run every branch every day.
- Pushes to branches will only run automatic builds if they target
- Any branch can manually trigger the workflow (that's
- Pull requests will only run builds when they target
live- Cron schedule will run every branch every day.
- Pushes to branches will only run automatic builds if they target
live- Any branch can manually trigger the workflow (that's
workflow_dispatch:).XI actually think that, since it's a PR coming from a branch outside the repo, it doesn't have the secrets and access, and thus can't push to GHCR.
XSo this PR might be running your workflow, actually.
AI dunno, it still makes no sense. The workflow inside the repo itself is the "action" that triggers.
X- Pull requests will only run builds when they target live.And this PR doesn't target live.
AHmm yeah it might be running MY local copy of the workflow instead of the upstream one i nstartingpoint.
XYeah the workflows and everything are in your repo.
AOkay that is good, that settles how workflows work in PRs. So they run in my local repo, not yours. Good security, phew.
XDo you even have the GHA enabled?
ANo. But I have some ideas how to fix this. We're gonna need some changes.
XAAh, yeah it's not visible there.
AI'm thinking atm, and will try to add
maintemplate to the auto-build targets.AAlternatively...
XWas just about to comment that.
XThen we'll just remove
main