Lo cerraste al rato de abrirlo, con razón no lo veía.

He copiado y pegado el código del repositorio a un repo aparte y le he aplicado por encima el main.yml (para no ensuciar mucho el historial, que las actions de por sí son un poco sucias), y tengo algunos problemas con algunos steps.

Por ejemplo, por el momento no voy a usar un semantic versioning muy estricto porque aunque estoy muy a tope con usarlo para bibliotecas, últimamente me he encontrado que en aplicaciones finales no es muy útil y no transmite mucho, y prefiero un enfoque donde incluso aunque haga algo que parezca breaking change (como cambiar una función de código), no incremente la mayor si el usuario no percibe cambios visuales evidentes.

Pero bueno, la base de la instalación de Rust y la compilación se podría aprovechar para compilar automáticamente más adelante y complementar al git-hook. Hasta que no arregle lo de los gresources para que pueda moverse la aplicación una vez compilada sin fallar al abrirse, no puedo ofrecer una descarga binaria porque ahora mismo por como se compila, te obligaría a poner el ejecutable en una carpeta concreta del ordenador.

Hola de nuevo Dani. La otra la cerré tal y como mencionas porque me di cuenta de que el binario tenía dependencias no embebidas y al compilarlo en el worker con un prefix personalizado, pedía paths del worker p.e su $HOME, etc.

En esta nueva PR el release asset contiene un tarball con un install.sh que sirve a su vez para purgar el binario/gresource/desktop_icons cuando no se quiera más el programa (en el runner se ha compilado sin prefixes para que esté enlazado con un well known path o como se diga jajaja). Si alguien quiere probarlo puede hacerlo de esta forma, estoy contigo aún así en que correr cualquier cosa con sudo echa bastante para atrás jejeje.

El tema de semver... Estuve mirando algunas actions y no me convencio ninguna, el step que pongo en la feature deja en manos del contributor bumpear la version, lo único que he hecho ha sido pillar el tag y sacar el changelog a la hora de hacer la release.

Eso es todo a grandes rasgos. La verdad es que me gustaría contribuir. De todas formas entiendo el punto de no poder distribuir aún el binario.

Sin mayor problema cierra la PR si no te convence o lo dejamos para más adelante, o como mencionas incorpora código para lo que te parezca, cualquier cosa me parece bien 👍🏻

Un saludo,

Sergio

Probé a compilar Cartero con una instalación limpia de MSYS2, y esto pasó...

Procedí a instalar todos los paquetes necesarios indicados en el archivo de compilación para Windows, y al momento de hacer el setup con Meson me topé con el siguiente error:

josal@DESKTOP-PUA53LS MINGW64 ~/cartero
$ meson setup build --prefix=/usr
The Meson build system
Version: 1.4.1
Source dir: C:/msys64/home/josal/cartero
Build dir: C:/msys64/home/josal/cartero/build
Build type: native build
Project name: cartero
Project version: 0.1
Rust compiler for the host machine: rustc -C linker=cc (rustc 1.79.0)
Rust linker for the host machine: rustc -C linker=cc ld.bfd 2.42
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: YES (C:\msys64\mingw64\bin/pkg-config.EXE) 2.2.0
Run-time dependency glib-2.0 found: YES 2.80.3
Run-time dependency gtk4 found: YES 4.14.4
Run-time dependency gtksourceview-5 found: YES 5.12.1
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency libadwaita-1 found: NO (tried pkgconfig)

meson.build:34:0: ERROR: Dependency "libadwaita-1" not found, tried pkgconfig

A full log can be found at C:/msys64/home/josal/cartero/build/meson-logs/meson-log.txt

Ante este error, procedí a instalar adwaita con el siguiente comando:

$ pacman -S mingw-w64-x86_64-libadwaita

Volví a ejecutar el comando meson setup build, esta vez reconociendo la existencia de adwaita en mi MSYS2 y dejándome seguir con la compilación. Por esta razón entra el primer paquete que propongo añadir a la lista de paquetes necesarios para compilar Cartero.

Luego de ello, ejecuté el comando ninja -C build y me topé con el siguiente error:

Nota: cabe decir que al no tener blueprint-compiler instalado, se me clonó el repo de dicho paquete en la carpeta subprojects de Cartero para usarse en la compilación.

josal@DESKTOP-PUA53LS MINGW64 ~/cartero
$ ninja -C build
ninja: Entering directory `build'
[1/7] Generating data/blueprints with a custom command
FAILED: data/endpoint_pane.ui data/main_window.ui data/key_value_pane.ui data/key_value_row.ui data/response_panel.ui
"C:/msys64/mingw64/bin/python.exe" "C:/msys64/home/josal/cartero/build/subprojects/blueprint-compiler/blueprint-compiler" "batch-compile" "data" "../data" "../data/ui/endpo
int_pane.blp" "../data/ui/main_window.blp" "../data/ui/key_value_pane.blp" "../data/ui/key_value_row.blp" "../data/ui/response_panel.blp"
Traceback (most recent call last):
  File "C:/msys64/home/josal/cartero/build/subprojects/blueprint-compiler/blueprint-compiler", line 38, in <module>
    from blueprintcompiler import main
  File "C:/msys64/home/josal/cartero/subprojects/blueprint-compiler/blueprintcompiler/main.py", line 27, in <module>
    from . import formatter, interactive_port, parser, tokenizer
  File "C:/msys64/home/josal/cartero/subprojects/blueprint-compiler/blueprintcompiler/interactive_port.py", line 25, in <module>
    from . import decompiler, parser, tokenizer
  File "C:/msys64/home/josal/cartero/subprojects/blueprint-compiler/blueprintcompiler/decompiler.py", line 26, in <module>
    from .gir import *
  File "C:/msys64/home/josal/cartero/subprojects/blueprint-compiler/blueprintcompiler/gir.py", line 25, in <module>
    import gi  # type: ignore
    ^^^^^^^^^
ModuleNotFoundError: No module named 'gi'
[4/7] Building translation po/eo/LC_MESSAGES/cartero-eo.mo
ninja: build stopped: subcommand failed.

Para solucionar este error, lo que hice fue instalar blueprint-compiler en mi MSYS2 directamente:

$ pacman -S mingw-w64-x86_64-blueprint-compiler

Una vez hecho esto, volví a ejecutar el comando y no me volvió a generar este error y me permitió seguir con la compilación. De aquí viene el segundo paquete que propongo añadir a la lista.

Luego seguí con la ejecución de comandos normales para compilar Cartero y no me generó más problemas, hasta incluso fuí capaz de abrir Cartero correctamente.

Estas son las razones por las que creería yo que sería importante añadir estos dos paquetes en la compilación de Windows. Podré estar equivocado, sin embargo aquí dejo mi pequeño granito de arena para querer aportar al proyecto.

It is known that currently some application icons may not present properly. This issue affects any version that is not packaged via Flatpak: Windows, macOS and non-sandbox GNU/Linux.

I'm looking for workarounds and I'll probably just embed some icons into the application to make sure that they always work.

I just downloaded the windows and tried to execute a common POST request that I use but didnt work, I'm not sure maybe Im indenting wrong or something like that

This is the request in postman

This is the request in Cartero:

In this pr am including two main files which are being used by nix to be able to build and install cartero in a nixos (and non nixos systems that use the standalone nix package manager installation). A little bit resume of the changes is:

• flake.nix: This file is the entry point for a nixos built system using the flakes way which is an experimental new way of using nix but being pretty much adopted nowadays in the nix ecosystem.
• default.nix: The cartero nix derivation. You can think on a derivation as something like a recipe or a makefile which tells nix how to build the application, and also what files/services/configurations it should touch in the system, all of this happen by keeping every binary/library isolated from the real system.

[!NOTE] Instructions to install and use were included in the README.md but feel to suggest changes if needed or edit if you want aswell 😁

Cartero running on nixos with plasma.

They currently cause issues on Windows and macOS.

• On Windows, they cause weird shadows to appear, and the alternative to shadows is even worse (see #19).
• Also on Windows, they are not fully compatible with features like window snapping
• On macOS, window controls are not native and are in the opposite side of the Window

A way to disable CSD during compile-time should be added to Cartero. I believe that it should be implemented as a feature, to make it easier to test it even on GNU/Linux, or even to facilitate the integration with desktop environments that do not follow the GNOME HIG, such as KDE.

• If CSD is enabled, CarteroWindow will extend Adw.ApplicationWindow, and the Blueprint shall reflect it. This is the current behaviour.
• If CSD is disabled, CarteroWindow will extend Gtk.ApplicationWindow instead, and should use a different Blueprint that adapts to the Gtk.ApplicationWindow limitations.

Also, on Windows disabling the CSDs shall set the GTK_CSD env-var to "0", because it seems that on Windows, Gtk.ApplicationWindow will try to be non-native unless the environment variable is set.

Allow to mask a value input so that the contents are not visible out of the box, which is good to encode API keys and other sensible data that you'd rather not show, for instance, if screensharing.

This requires storing data in the KeyValue data structure, since the information is also required to avoid serializing the value into a file.

Depending on the value of the content-type header for the response, I could load a specific syntax highlighter, such as JSON, TOML, YAML, HTML or XML.

Ey, aquí dejo el CICD para crear la release de Cartero como te mencione ayer por YT 😄

Tengo de TODO añadir semantic versioning a futuro pero tu mandas.

Un abrazo,

Sergio

List of shortcuts to add for 0.1:

• [x] <Primary>-T: open a new tab.
• [x] <Primary>-O: open an existing file.
• [x] <Primary>-S: save or prompt to save new file.
• [x] <Primary>-W: close tab.
• [x] <Primary>-Q: exit Cartero.
• [ ] <Primary>--S: save as new file.

Say that you try to exit Cartero with a modified file. You press Save, but you cancel instead. Currently, Cartero will exit. The expected behaviour is that the close process is aborted and therefore you have to quit Cartero again.

First of all, i'm sorry

I need to say that i am not a rust/gtk dev, maybe I shouldn't do this

Sometimes responses json type dont format correctly on body panel

for that i applied some lines for try render a bit better json values

I'm not sure if this help or improve performance with long single line

• [x] add serde_json dependency
• [x] format response with to_string_pretty fn
• [x] set the format to panel

i really apreciate any type of feedback and tips, or if I can help you in other ways i'll do it with pleasure

pd: i like yout content, you do a great job

Most programs like this have a tab for this, and when using Cartero I find that not having a feature like this makes my work more difficult.

There should be an additional tab called Parameters, with a KeyValuePane inside.

Modifying the URL in the request_url field should update the parameters presented in the field. Modifying the contents of the KeyValuePane for the parameters should cause the parameters to be grouped again into a querystring, and the request_url should have its current URL changed as well.

Disabling a param from the pane should remove it from the URL as well.

I believe this is going to be tricky because changing the contents of the request_url after touching the pane may cause a "request_url has changed" event to fire back, entering an infinite loop. I suspect I'm going to need to add a mutex that prevents both event listeners from trying to update one each other.

It is known that currently some HTTP requests that use HTTP streaming may hang the user interface. An example request of this is https://httpbin.org/range/1500. Other requests may exist.

In general, support for streaming requests and server side events is currently not well tested and this will probably not change until 0.1 gets released in order to focus my limited resources into finishing the first version of the app.

The macOS version doesn't use the proper keyboard shortcuts for some actions such as cut, copy, paste and select all.

This is a known issue that affects upstream dependencies, and there is not much to fix here at the moment, so I'm marking this as a Known issue if someone ever reports this as a bug in Cartero.

More context: currently, GTK 4 apps use <Ctrl> as the primary modifier for all keyboard shortcuts. On GNU/Linux and Windows this makes sense because the keyboard shortcuts are already Ctrl-X, Ctrl-C, Ctrl-V. However, on macOS most users will expect Cmd-X, Cmd-C and Cmd-V as the keyboard shortcuts to cut, copy and paste.

Solution 1: upstream GTK. On GTK 4.16, they will change the primary modifier to <Meta> (the Cmd key) on macOS. The merge request has been already integrated. If we just wait until GTK 4.16 is stable, once it is possible to compile a macOS version with that version, the issue will probably be automatically fixed.

Solution 2: language bindings. There is a workaround to change the keyboard shortcuts for cut, copy and paste. Many apps already use it to have better compatibility with macOS. Unfortunately, there seems to be some kind of issue at the moment with the language bindings for the UI toolkit that Cartero uses which currently prevents me from using the workaround in my application.

This is my take on #11.

The goal is to allow the user to create collections, which will have endpoints inside. It should be possible to create, open, save and close collections, and for each collection, the application shall let the user manage folders and requests.

Tasks and subtasks:

• [x] Create collections.
• [x] Open existing collections by pointing at the metadata file.
• [x] Close existing collections
• [ ] Update information about collections.
• [ ] Support for requests and folders (to-do...)

Known issues:

• [ ] Pressing Enter on the New Collection dialog should submit the form.

Here is an updated screenshot with the state of this feature.

Here we see the list of opened collections.

By pressing the [Add] button, you can create a new collection.