Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Cartero 0.3 Beta 2

The second milestone towards 0.3 Beta 2. Addresses some of the received feedback, fixes a couple of bugs and adds useful features. Some of them will probably be backported to the 0.2 in the meantime to make them available to users of the stable channel too.

Support for .env files

.env files are commonly used in software projects to store credentials, API keys and other sensitive values that you need to run the application, but that you wouldn't like to keep static in the source code of your program. Or just to store local variables for your development machine that you don't want shared with your team.

Starting with Cartero 0.3 Beta 2, if there is an .env file near your request files (in the same directory or in a parent directory), the variables in that file can be automatically picked by Cartero to be used as part of your web requests. This is useful because secret keys are... well, secret; so you wouldn't want them stored in your request files, specially if you want to commit your requests to a Git repository to share them with your team.

Or you can use them to store common variables that you want to share among multiple request files, at least until actual support for collections arrives in Cartero, this century or the next one.

Support for reading env files has to be enabled in the settings. It's just a checkbox to tick, but you have to do it before it works. Don't worry, Cartero will remind you in the variables panel that env files are disabled and therefore not being read. Plus, once the checkbox is enabled, it will continue to work (unless you disable the option again).

The reason why you have to manually enable this is because .env files are not a joke. They can contain sensitive values, and if you receive a rogue request file or are not cautious enough, you could accidentally send your API keys to the wrong server. In the future, Cartero will probably have additional security settings to prevent rogue requests from being accidentally submitted.

Additionally, I don't think it's appropiate to read your .env file unless you're expecting so.

A screenshot of Cartero showing a request with environment variables that are being picked from a file as described above

Proxy settings

Cartero now has a settings panel to configure the proxy in use.

Cartero can actually use the system proxy settings if you pass the options through the http_proxy, https_proxy and no_proxy environment variables, as defined in the environment variables read by curl. It's just that this option has never been actually disclosed in the program.

Now, Cartero has a new settings page that allows you to manually define the HTTP and HTTPS proxy, as well as manage your exclude list, to disable the usage of proxies in specific domains. (Note that there is no allow list; in other words, you cannot choose to only use the proxy for some specific sites.)

A screenshot of the settings dialog of Cartero showing the proxy configuration

If these settings are empty, the system variables will still be used as a fallback. However, there are now additional options to disable the use of the standard curl environment variables, in situations where you don't want Cartero to use a proxy at all, even if the environment variables are present.

New look and feel for the settings window

Speaking of settings: you might notice that the settings window looks different now.

The number of options is going to grow as new features are added to the program, and the previous navigator was too limiting. Cartero now uses a full sidebar to manage the settings, to make things easier to scan and manage. In the future, the sidebar will receive a search button to quickly look for a specific setting, because I predict this will get chaotic.

Share your thoughts about this change if you have concerns or ideas.

Pre-generated headers in the request notebook

You can now use a toggle button to inspect additional headers that will be sent with your HTTP request.

These headers are either added automatically by the runtime, such as the User-Agent or the Host header, or are added as a consequence of your authentication or body settings (such as the Content-Type or Authorization headers).

These values are always low priority. This means that if you manually add your own User-Agent, Content-Type or similar header, it will use your value rather than the pre-generated one.

A screenshot of Cartero showing some headers

A faster way to start exploring endpoints

Starting with this beta, whenever you create a new endpoint via the New tab button, the menu or the keyboard shortcut, the entry URL will automatically receive focus, so that you can start typing the URL rather than having to manually click or tab to the entry by yourself.

It's a small change, and many other programs out there also have this feature, but it will save a lot of time for users who have to make a lot of HTTP requests. This one will probably be backported to a future 0.2.5 release for users of the stable channel.

Exporter bonanza

Cartero 0.3 Beta 1 enhanced the export process, with a new menu to export a request to more formats, and support for exporting responses too. In Cartero 0.3 Beta 2, some reported bugs have been fixed, specially when it comes to valid URLs that the export dialog rejects, or failures when you try to export a request that uses a file as body.

We are using a new template engine for our exporters. This means that it will gradually become easier to write new output formats, such as code snippets ready to paste into your programming editor or additional formats like OpenAPI, Bru or Postman-JSON.

The cURL exporter now supports every payload body type, including multipart, which previously was not supported. Additionally, the cURL exporter will now favour using native cURL flags, such as -u, --oauth2-bearer or -F, instead of just smashing every pre-generated header as a -H.

A screenshot of the Cartero exporter showing the usage of the new flags

Finally, when you try to export a response body (such as downloading a file or exporting a big JSON), the "Export response as" file dialog will now suggest a default file name based on the request URL (like users if your request was /api/v1/users). If the HTTP response actually uses the Content-Disposition header to disclose the original file name of the resource (in other words, if the URL points to a download), it will prefer the file name sent by the server. Of course, you're free to change the file name to whatever you need.

New welcome screen

Cartero is free software. You can use it without asking for permission or requiring licenses or subscriptions. The welcome page will now include a banner to remind you about this, and a button so that you can know your user rights, such as being able to use this tool at work or being allowed to modify and patch the program.

Additionally, some quick links have been added to the welcome page, such as the user manual, the bug tracker or our Mastodon account for social updates.

The welcome screen will change in the future, and the banner might be moved to a different location it's found too distracting.

Microsoft Fluent

If you are running Cartero on Windows 11, you might have noticed that in the past Cartero has always felt an outsider, despite being always promoted as a "native" alternative. Given that Cartero is actually an application that tries to follow the GNOME Human Interface Guidelines, when you run the application outside of the GNOME desktop environment it looks out of its place, including using the default Adwaita theme even on Windows and macOS.

For this beta, I've invested some time in how the application actually looks in Microsoft Windows, and the application now supports the use of backdrops when you run the application in Windows 11, following the Microsoft Fluent 2 design guidelines.

The application is still using the Adwaita theme from GNOME, but there are some widgets that look like frosted glass, including the toolbar and additional windows like the Settings dialog, similar to the look and feel of apps like the Windows Calculator, Windows Paint or Windows Notepad.

A screenshot of Cartero showing some subtle transparency effects

Upgraded dependencies

Cartero now requires GLib 2.80 and GtkSourceView 5.14 to build. These dependencies are part of GNOME SDK version 46.

If you're on Ubuntu, the minimum version that supprots compiling Cartero without additional help is Ubuntu 24.04, as this version uses GNOME 46 and its dependencies. More recent versions of Ubuntu will work too, of course. On Ubuntu 22.04 and older versions, it might not compile because the provided versions are too old.

Cartero now builds successfully on Debian Trixie without further help too, because it packs with a GNOME version recent enough to suit the checks. On Debian 12, Cartero will not be able to compile unless you manually backport the GNOME SDK from a different source.

You should also be able to compile Cartero with any supported Fedora version.

Fixes

Here is a quick list of all the things fixed in this beta:

Back in 0.3 Beta 1, some changes were made to the authentication and body panes. Unfortunately, in Beta 1, if you change the authentication or body type (say, you change from basic auth to bearer token, or you change from multipart to raw), the old settings were lost, with no ability to undo.

Starting with Beta 2, we've restored the proper behaviour as it used to be in 0.2. As long as you don't close the tab, you will be able to switch back to the previous authentication or body type, and the old settings will still be there.

While we're at this, I've fixed a longstanding annoyance in Cartero where the settings for multipart and urlencoded bodies are not shared. Previously, each body type had a different table, and switching from one type to the other would require you to type again all the key-value entries in the table. Now, switching the body type will keep the entries. This will get more difficult once support for multipart files land, because these are exclusive to multipart, but we will still be able to share the inline text parts.

It was reported that the exporters added in 0.3 Beta 1 failed to export requests where the body type was set to raw, and that sometimes it would reject an otherwise valid URL. These bugs have been fixed and it should accept any URLs even if they don't start with http:// or https://.

Also, on macOS the Export dialogs did not actually copy the generated output to the clipboard when the "Copy to clipboard" button was pressed, due to a bug in the clipborad implementation that only affects macOS and that has been fixed now.

Finally, on macOS a bug has been fixed where pressing Command + L to focus the Request URL entry did not work. You had to actually press the Ctrl key, which is not how most macOS applications work. Now you can actually use the Command key, as expected.

Finally, on Microsoft Windows, the language chooser added to the settings page in Cartero 0.3 Beta 1 didn't work. The application would still use the system language after a restart. This has been fixed.

What about 0.3 Beta 3?

Yes, there will be a 0.3 Beta 3. There are still more features waiting to be done. I am still working on making changes to the internal architecture of the program so that it can work with collections.

Specifically, because of the way I want collections to work in Cartero, I need to make sure that it supports multiple windows. Currently, this is not possible because the system assumes that there is always one window in execution. I am still making changes to the application shell so that you can have multiple windows with tabs.

This is trickier than what it looks like because some features of Cartero such as not opening the same request twice must continue to work. If Cartero detects that a request is already opened in a tab in any window, it has to focus that window and bring that select that tab.

All of this is making me realize that currently Cartero does a very poor job on keeping track of which files are actually opened. I am working on a new document repository for Cartero that allows to handle these things better, and also to clean up the way loading and saving files work. The good news is that these changes will come handy in the future, when Cartero supports additional things that are not HTTP requests and that require their own file formats and tabs, such as gRPC requests or WebSocket sessions.

And then, there's collections themselves.

But also, there are features like attaching requests to multipart requests or supporting OAuth 2.0 as an authentication type that are on the menu for 0.3. Keep an eye on the milestone, the tracking issue and the kanban to see how things are going.