Pinned
Troubleshooting
Fix blank screen / Crash on Linux due to Wayland, NVIDIA, etc
Possible error messages: Error 71 (Protocol error) dispatching to Wayland display Cannot create EGL context: invalid display If Yaak crashes or shows a blank screen on Linux, try setting one of the following environment variables: WEBKIT_DISABLE_COMPOSITING_MODE=1 forces accelerated compositing off in WebKitGTK. WEBKIT_DISABLE_DMABUF_RENDERER=1 disables the newer DMA-BUF renderer, which is the default in recent WebKitGTK and is generally the right path—except it’s been flaky with NVIDIA proprietary drivers(white/blank screens, flicker). __NV_DISABLE_EXPLICIT_SYNC=1 makes the driver / EGL-Wayland layer turn off or ignore the explicit sync path and fall back to older (less strict) synchronization paths
Kendrick Ha 7 months ago
Bug
Pinned
Troubleshooting
Fix blank screen / Crash on Linux due to Wayland, NVIDIA, etc
Possible error messages: Error 71 (Protocol error) dispatching to Wayland display Cannot create EGL context: invalid display If Yaak crashes or shows a blank screen on Linux, try setting one of the following environment variables: WEBKIT_DISABLE_COMPOSITING_MODE=1 forces accelerated compositing off in WebKitGTK. WEBKIT_DISABLE_DMABUF_RENDERER=1 disables the newer DMA-BUF renderer, which is the default in recent WebKitGTK and is generally the right path—except it’s been flaky with NVIDIA proprietary drivers(white/blank screens, flicker). __NV_DISABLE_EXPLICIT_SYNC=1 makes the driver / EGL-Wayland layer turn off or ignore the explicit sync path and fall back to older (less strict) synchronization paths
Kendrick Ha 7 months ago
Bug
Backlog
flatpak & flathub
Please consider distributing a flatpak version published on flathub, with the minimm required permissions i.e. network access only All currently distributed Linux versions involve trusting you & your supply chain with everything our logged in user has access to i.e. all of our data
synotna Over 1 year ago
Improvement
Backlog
flatpak & flathub
Please consider distributing a flatpak version published on flathub, with the minimm required permissions i.e. network access only All currently distributed Linux versions involve trusting you & your supply chain with everything our logged in user has access to i.e. all of our data
synotna Over 1 year ago
Improvement
Allow commenting json body
When making JSON POST request to allow adding comments, sometimes i dont want to POST particular data so i would comment them
Marius Almost 2 years ago
Feature
Allow commenting json body
When making JSON POST request to allow adding comments, sometimes i dont want to POST particular data so i would comment them
Marius Almost 2 years ago
Feature
Up Next
Save Request Data for Response History
(thanks for all your work on this app!) First of all, I love that Yaak keeps a response history - this was one of my gripes with HTTPie. I am wondering if its intentional that the response history does not store the request data in sync with the response data. Like if I select an older response from the history, there’s no telling what the actual request was that lead to that response - it doesn’t necessarily have to be what is currently on the request editor pane. I think that disconnect is a bit confusing. But I don’t know if thats intentional - perhaps the way most people use this is to store histories of the exact same request, and if they wanted to modify even one value, they make a fresh copy of the request? The other thing is I think it would be super useful to show some kind of timestamp type information about when that response in the history was made. Either in the drop-down, or in the header text above the response where it says the status, query time, response size. Could be one of those present-relative strings to keep it as short as possible if thats a concern - like 3m ago, or 2h30m ago, etc
Anirudh Thommandram 11 months ago
Question
Up Next
Save Request Data for Response History
(thanks for all your work on this app!) First of all, I love that Yaak keeps a response history - this was one of my gripes with HTTPie. I am wondering if its intentional that the response history does not store the request data in sync with the response data. Like if I select an older response from the history, there’s no telling what the actual request was that lead to that response - it doesn’t necessarily have to be what is currently on the request editor pane. I think that disconnect is a bit confusing. But I don’t know if thats intentional - perhaps the way most people use this is to store histories of the exact same request, and if they wanted to modify even one value, they make a fresh copy of the request? The other thing is I think it would be super useful to show some kind of timestamp type information about when that response in the history was made. Either in the drop-down, or in the header text above the response where it says the status, query time, response size. Could be one of those present-relative strings to keep it as short as possible if thats a concern - like 3m ago, or 2h30m ago, etc
Anirudh Thommandram 11 months ago
Question
Export to OpenAPI
I work with people who use other HTTP tools. Being able to export to OpenAPI would allow me to collaborate with them, regardless of the tool they use.
Fletcher Over 1 year ago
Feature
Export to OpenAPI
I work with people who use other HTTP tools. Being able to export to OpenAPI would allow me to collaborate with them, regardless of the tool they use.
Fletcher Over 1 year ago
Feature
Up Next
Update current workspace during import
When importing non-Yaak files, it should be possible to import the same spec again and have it update the workspace, instead of always creating a new one.
Viktor Kojouharov 10 months ago
Improvement
Up Next
Update current workspace during import
When importing non-Yaak files, it should be possible to import the same spec again and have it update the workspace, instead of always creating a new one.
Viktor Kojouharov 10 months ago
Improvement
Up Next
Request history, time stamp
In the request history https://share.zight.com/Apud4WZ7 - add a timestamp, something similar to Insomnia: https://share.zight.com/bLuLEL1G It would be nice to see a small time/date next to each request.
Steve 3 months ago
Feature
Up Next
Request history, time stamp
In the request history https://share.zight.com/Apud4WZ7 - add a timestamp, something similar to Insomnia: https://share.zight.com/bLuLEL1G It would be nice to see a small time/date next to each request.
Steve 3 months ago
Feature
Backlog
Save request/response examples
hoppscotch feature, also postman Manually save request example (with response/request ino)
A Bliss 8 months ago
Feature
Backlog
Save request/response examples
hoppscotch feature, also postman Manually save request example (with response/request ino)
A Bliss 8 months ago
Feature
Support for http files (VSCode REST Client / IntelliJ HTTP Client)
For the developers in our Company we found using http files with VSCode REST Client (https://marketplace.visualstudio.com/items?itemName=humao.rest-client) or IntelliJ HTTP Client (https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html) the most vendor agnostic way to work with http requests. The file format is very close to the actual HTTP Protocol and is very nice to manage in a VCS like git. Variables make it easy for non-technical people to work with these files but it would be even better if they could use these files in Yaak. Related: https://github.com/usebruno/bruno/issues/1537, https://github.com/ArchGPT/insomnium/discussions/149
Pierre Kisters Over 1 year ago
Improvement
Support for http files (VSCode REST Client / IntelliJ HTTP Client)
For the developers in our Company we found using http files with VSCode REST Client (https://marketplace.visualstudio.com/items?itemName=humao.rest-client) or IntelliJ HTTP Client (https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html) the most vendor agnostic way to work with http requests. The file format is very close to the actual HTTP Protocol and is very nice to manage in a VCS like git. Variables make it easy for non-technical people to work with these files but it would be even better if they could use these files in Yaak. Related: https://github.com/usebruno/bruno/issues/1537, https://github.com/ArchGPT/insomnium/discussions/149
Pierre Kisters Over 1 year ago
Improvement
Backlog
Scripting is a must
It is not quite true that after importing Insomnia one can start immediately. We have some elaborated requests flow which can’t be a match for the request chaining, so no, the suite is not working straight away in Yaak after import, and migration is not possible.
Patrick Diligent About 2 months ago
Improvement
Backlog
Scripting is a must
It is not quite true that after importing Insomnia one can start immediately. We have some elaborated requests flow which can’t be a match for the request chaining, so no, the suite is not working straight away in Yaak after import, and migration is not possible.
Patrick Diligent About 2 months ago
Improvement
feature: Support OpenAPI URL Synchronization for API Import
Currently, the API import feature only supports file upload. I would like to propose adding support for importing APIs through OpenAPI URL synchronization. This would allow users to: Add their local Swagger JSON URL directly to the system Use a sync button to import new APIs whenever the source API documentation is updated Maintain a real-time connection between the source OpenAPI documentation and the imported APIs Benefits: Streamlines the API import process Reduces manual work for keeping APIs up-to-date Ensures API documentation stays synchronized with the source Particularly useful for developers working with local Swagger instances Proposed Implementation: Add an alternative import method that allows users to: Input an OpenAPI/Swagger URL Validate the URL and fetch initial API documentation Provide a sync button to refresh/update the APIs when needed
erguotou About 1 year ago
Feature
feature: Support OpenAPI URL Synchronization for API Import
Currently, the API import feature only supports file upload. I would like to propose adding support for importing APIs through OpenAPI URL synchronization. This would allow users to: Add their local Swagger JSON URL directly to the system Use a sync button to import new APIs whenever the source API documentation is updated Maintain a real-time connection between the source OpenAPI documentation and the imported APIs Benefits: Streamlines the API import process Reduces manual work for keeping APIs up-to-date Ensures API documentation stays synchronized with the source Particularly useful for developers working with local Swagger instances Proposed Implementation: Add an alternative import method that allows users to: Input an OpenAPI/Swagger URL Validate the URL and fetch initial API documentation Provide a sync button to refresh/update the APIs when needed
erguotou About 1 year ago
Feature
Nested environment variables
One of the main reasons I used Insomnia was for the environment variable file structure. The JSON nested variables allowed for a much more flexible and organized list, especially in larger environment variable lists. I don't really mind the loss of JSON (although, it is nice to have a portable format like that), but the loss of nested variables is really disappointing.
Alex Coté Over 1 year ago
Feature
Nested environment variables
One of the main reasons I used Insomnia was for the environment variable file structure. The JSON nested variables allowed for a much more flexible and organized list, especially in larger environment variable lists. I don't really mind the loss of JSON (although, it is nice to have a portable format like that), but the loss of nested variables is really disappointing.
Alex Coté Over 1 year ago
Feature
Backlog
Would you rethink about the env var config view?
Hello, have a good day! I feel it's very convenience if configuring env vars could always show me all environment variables and also the fallback value. It will help to know which one will be used, and which one is misconfigured. I never saw any http client has this kind of view except Httpie Desktop. Would you consider to make Yaak env var config view become something like this? If that's possible. I would suggest: No need to show all the environments like LOCAL, PROD as the screenshot, but only Defaults and current env could be more optimized as some variable could have value as long string. Thanks!
Vuong Over 1 year ago
Improvement
Backlog
Would you rethink about the env var config view?
Hello, have a good day! I feel it's very convenience if configuring env vars could always show me all environment variables and also the fallback value. It will help to know which one will be used, and which one is misconfigured. I never saw any http client has this kind of view except Httpie Desktop. Would you consider to make Yaak env var config view become something like this? If that's possible. I would suggest: No need to show all the environments like LOCAL, PROD as the screenshot, but only Defaults and current env could be more optimized as some variable could have value as long string. Thanks!
Vuong Over 1 year ago
Improvement
