Feedback on v0.9.0.23

[stamminator]

Hi @U-C-S, great job with this release. The problems I had with the settings menu not working in the alpha build are gone. Design-wise, I applaud the way the settings app's sidebar nav looks. It acts like a proper desktop app. The default behavior most Fluent design apps use, which either has the menu totally minimized or expanded way too wide at some unintuitive breakpoint, is very annoying (screen recording for example):

Here are my main critiques in order of importance. I believe all of these are long-standing and not specific to this build, but some of them are major pain points for me when using this app, and therefore worth mentioning.

Major

1. Please do not close the Hurl window until I either select a browser or press the X (minimize to tray) button. I find it to be a frustrating behavior for this window to close when I click anything other than the window.
2. Allow installation of a new version without first requiring that the user manually uninstall the prior version.

Minor

3. Allow changes in the settings to take effect without requiring the user to manually right-click > Exit Hurl.

Very minor nitpicks

4. Improve the rendering of icons. Looks like some suboptimal anti-aliasing. Here's a link to the exact icon file I'm using for the one in the middle that looks particularly bad.

5. The Hurl dropdown menu should use the standard toggle behavior when clicked rather than reopening an already-open dropdown.

6. The default settings window size is quite big, 1202 x 872 by my measurement. Something like 900 x 600 is more than sufficient and makes it feel less intrusive.

[U-C-S]

Thanks for taking time and putting a feedback here. It's really helpful in understanding how others use the application.

---

Please do not close the Hurl window until I either select a browser or press the X (minimize to tray) button.

This could be a toggle from the settings. Shall put it for a release soon. I personally prefer the way it currently is, hence why it is that way haha.

---

Allow installation of a new version without first requiring that the user manually uninstall the prior version

This is just optional something I could worded better in the release notes. since I encountered some issues myself during testing. (I forgot but probably related to Hurl now reciding in Program Files instead of Program Files (x86)

---

changes in the settings to take effect without requiring the user to manually right-click > Exit Hurl.

This is something I want to do in next release. Already have a prototype but don't want to have a feature creep for 0.9

---

Improve the rendering of icons

Also this one

---

default settings window size is quite big, 1202 x 872

Window sizing of Settings is a concern I had during dev. I need to more time to study/understand how WPF/WinUI apps does it.

[Jay-o-Way]

Hi @stamminator thanks for the message. @U-C-S already responded to most, I just wanted to share some words of mine.

1. (do not auto close the Hurl window) We agree!
2. (without requiring manually uninstall) Agree. Have to look into the "how".
3. (apply changes) Yep, great idea.
4. (rendering of icons) The cause here lies with the file. ICO files don't scale as smoothly as i.e. SVG will. Default icons looks perfect on my end. FYI @U-C-S the user's icon file is 128×128px and the BrowserButton is also 128, but it has paddings. Might be better to set a size on the actual \<Image> element.
5. (dropdown) As far as I know, this is default?
6. (window size) Totally agree!

[eidylon]

Yes, definitely make "do not auto-close" a setting... though I'd say make it a checkbox on the bottom of the main window, instead of (or in addition to) buried in settings.

I wholly agree with @U-C-S that it should auto-close. After I've selected the browser for a link, I don't need that window to be hanging around just doing nothing, leaving me to then have to click the [X] every time to close it.

Not sure why you would want it to stay around, but ... clearly others have some use-case for that. So definitely if this is added, it should be a setting, preferably defaulting to enabled.

[stamminator]

Thank you both for the response. Some additional notes on the above feedback:

1 - (do not auto close the Hurl window) I would suggest that, once the setting is implemented, keeping the window open rather than closing upon an external click should be the default behavior, as I suspect this is what most people would expect. But as long as the option exists even if it's not the default, I'll be very happy.

4 - (rendering of icons) Aren't the default Firefox and Edge icons also using ICO, the ones embedded in the EXEs? I'm not aware of any SVGs that are being used.

5 - (dropdown) Here is the default toggle behavior I'm referring to.

[stamminator]

@U-C-S At this risk of putting too much in this issue, I just want to mention one more thing. I sometimes find that more than one link is opened at a time before I have a chance to respond to either of them. A common use case is when you use Visual Studio or Rider to launch multiple web projects at once, e.g. http://localhost:50001 and http://localhost:50002. Last time I tested this, it didn't work too well. Do you know if this is a supported use case? If not, perhaps we could discuss a spec for a queuing feature.

[stamminator]

I wholly agree with @U-C-S that it should auto-close. After I've selected the browser for a link, I don't need that window to be hanging around just doing nothing, leaving me to then have to click the [X] every time to close it.

Not sure why you would want it to stay around, but ... clearly others have some use-case for that. So definitely if this is added, it should be a setting, preferably defaulting to enabled.

@eidylon I'm definitely not suggesting the window hang around after a browser is selected. I'm suggesting that the current behavior, which is to close the window if the user does some external click in the background, be changed (or configurable) so that the window persists until either a browser is selected in Hurl or the X button is pressed. Here's an example of what @Jay-o-Way initially referred to as auto-closing. Notice how a subsequent click closes Hurl:

Yes, definitely make "do not auto-close" a setting... though I'd say make it a checkbox on the bottom of the main window, instead of (or in addition to) buried in settings.

This might be nice, but having a satisfactorily detailed label/description such that the checkbox's purpose is clear to the user would probably take up too much space in the Hurl UI, which is intended to be minimal. I think just an option in the settings is fine.

[eidylon]

@eidylon I'm definitely not suggesting the window hang around after a browser is selected. I'm suggesting that the current behavior, which is to close the window if the user does some external click in the background, be changed (or configurable) so that the window persists until either a browser is selected in Hurl or the X button is pressed.

@stamminator Ahh! Gotcha... yeah, that makes a lot more sense! 😂 ... I misunderstood your original idea. Given that clarification, yeah, this wouldn't need to be on the main screen then. I concur.

[U-C-S]

do not close the Hurl window until I either select a browser or press the X

Implemented it, currently in main. default being it minimizes (might come back to what should be the default before a release)

---

launch multiple web projects at once, e.g. http://localhost:50001 and http://localhost:50002 discuss a spec for a queuing feature

I wanted something similar some time ago. Right now not a priority

(dropdown) As far as I know, this is default?

Yes, it's the default behavior from WPF-UI. I will experiment with WinUI port of Hurl.BrowserSelector project sometime soon, which might resolve this and few other issues with UI if it works.

Allow changes in the settings to take effect without requiring the user to manually right-click > Exit Hurl.

I experimented on this again since last reply. while I could get few features to work and rest (like browsers) still needed a restart because of the way application is architectured. Best I could do is detect changes and notify the user to reload themselves or possibly reload automatically on next use.

[stamminator]

@U-C-S Thank you! I'm running commit 8e18e06 and "Minimize on Focus Loss" set to off is working great. I just submitted a PR to fix a dev environment issue I ran into, but it's unrelated to any of these features. I think setting the default to off instead of on will be preferred for most people, but either way, it'll be well-received.

If it's not too complex, I think auto-reloading the app when the settings are changed is the way to go. Other than that, I agree the other issues are low priority. Definitely worth a dedicated release once both of these are in place.