gitbutlerapp
Tauri v1 -> v2
- rewrite of app updater because of new api
- webkit2gtk 4.0 -> 4.1 upgrade, will now work without appimage on Ubuntu 24.04
- webdriver actions API now working
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| gitbutler-web | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Oct 30, 2024 0:30am |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
@ndom91 I think this works pretty well, would you mind giving it a test-run today?
The only thing currently on my mind are the json files under crates/gitbutler-tauri/capabilities. One of them was automatically created by the migration script, we should probably move its contents over into the other one.
@mtsgrd yeah so I was able to fire it up in dev mode no problem after applyign that small fix from my commit ^^ :+1:
Regarding the capabilities, yeah so that migration one seems to just add a core:default permission, right. I couldn't find exactly what that enables/allows in their docs, but it seems like, well, a core one :sweat_smile: that we probably can just move over to the main.json as you mentioned :+1:
A quick note on the tests - they started up locally for me without a problem, and after remembering to upgrade to [email protected] they also ran without issue with your updated findAndClick() :partying_face:
I just noticed that #4128 (Distribute as VSCode extension) has a stunning amount of upvotes, and I thought I'd mention it here in case this PR in any way facilitates getting there.
I just noticed that #4128 (Distribute as VSCode extension) has a stunning amount of upvotes, and I thought I'd mention it here in case this PR in any way facilitates getting there.
While there doesn't seem to be any official tauri-supported way to build and package a tauri code base into a VS Code extension. We could, hwoever, continue with the Tauri-based CLI and package that up with a VS Code extension. Hypothetically, the VS Code extension could then just be a "frontend" to the CLI
We could, hwoever, continue with the Tauri-based CLI and package that up with a VS Code extension. Hypothetically, the VS Code extension could then just be a "frontend" to the CLI
The CLI (as it exists currently) doesn't have any tauri in it, which probably helps with portability. Indeed, it sounds like currently one would have to rewrite the frontend for VSCode, which seems prohibitive.
However, from a technical standpoint I think tauri would be in the best position to enable vscode support. After all, it 'just' wouldn't have to open its own window. But that's for the future then, and maybe something to talk about next time Daniel is in town.
While there doesn't seem to be any official tauri-supported way to build and package a tauri code base into a VS Code extension. We could, hwoever, continue with the Tauri-based CLI and package that up with a VS Code extension. Hypothetically, the VS Code extension could then just be a "frontend" to the CLI
The CLI (as it exists currently) doesn't have any tauri in it, which probably helps with portability. Indeed, it sounds like currently one would have to rewrite the frontend for VSCode, which seems prohibitive. However, from a technical standpoint I think tauri would be in the best position to enable vscode support. After all, it 'just' wouldn't have to open its own window. But that's for the future then, and maybe something to talk about next time Daniel is in town.
A while back we had some conversations about wanting to support running a gitbutler server which could then talk to a gitbutler client over web socket or HTTPS. I've not read too much into the context of this conversation, but in my mind, I would want to approach anything that could create more lock-in to tauri's IPC or similar systems with caution.
