| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
1. narrow_layout is indeed unused, `AdwBreakpoint` remembers initial
values and restores them on load
2. `TagPillWidgets` is not exactly dead code, I'm adding all the
widgets to it to emulate how Relm4 macros do it. Perhaps it'll be used
in the future.
3. We currently ignore the libsecret result on clearing the tokens
because dealing with libsecret errors is annoying and requires unsafe
code due to outdated dependencies.
|
|
|
|
|
|
| |
This is a very shitty translation, but it can be improved later. I
added it mostly as a test for translations working correctly, since I
know Russian and might as well translate the app into the language.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Uses the macro again, tries to store only the relevant parts in
enums (i.e. the Micropub client, which requires a token).
|
| |
|
|
|
|
| |
Whoops
|
|
|
|
|
|
|
|
| |
I had to commit a minor safety crime (but not an unsoundness crime) to
get libsecret's `glib::Error` to be compatible with `glib::Error` from
the newer GLib version.
This could be dropped later when libsecret updates.
|
|
|
|
|
|
|
| |
This helps unify HTTP-related settings in one place.
In Relm4 Matrix chatroom, it was said that deconstructing child
components makes little sense in terms of optimizations.
|
|
|
|
|
|
| |
The code is really janky and unpolished, the error handling is
TERRIBLE, and I think I can't publish it like this. This'll need a
refactor, but it'll come tomorrow.
|
|
|
|
|
|
| |
This saves memory by dropping unneeded components. Once the app
changes state, it can simply drop the unnecessary component, such as
the login screen, to save memory.
|
| |
|
| |
|
|
|
|
|
| |
Now it's easy to use the same UI for sending a new post or editing an
existing one (by loading it with `?q=source` and then comparing).
|
| |
|
|
|
|
|
|
|
| |
What this command should do is construct a summarization request and
return a future which would return chunks from the LLM.
Perhaps this component will be asyncified in the future.
|
|
|
|
|
| |
On receving `smart_summary::Output::Start`, one must reply with
`smart_summary::Input::Text(text)` to start the actual summarization.
|
|
|
|
|
|
| |
This is a little bit janky in my opinion, because it takes a reference
to the buffer which contents its gonna be summarizing. In a perfect
world, it would ask the parent component for the text.
|
|
|
|
|
| |
Success toasts also display a button to open the post in your browser
of choice.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This makes it able to execute unsendable futures, and unlocks ability
for us to do asynchronous initialization and updates.
|
|
Currently the UI does precisely nothing, but the ✨ Smart Summary
button prints a message stating what it's supposed to do. The Post
button currently just logs to the console, although ultimately it
should send a message to a parent component or something.
Perhaps even the composer UI itself should be a separate part that can
provide an MF2-JSON document on a command.
|