New UI

[Jay-o-Way]

App-wide

• Mica with SystemThemeWatcher! 🥳
  • Fails on Windows 10 🙁 WPF-UI issue → https://github.com/lepoco/wpfui/pull/1094
  • Look out for v4.0 https://github.com/lepoco/wpfui/pull/1107
• Icons for the windows! 🥳
• Colors and styles
• Moved Buttons to the bottom (using a central Style)
• Using xmlns:wpfui= everywhere - no more ui=

Browser window

• Using TitleBar - Minimize button functions the same
• Logical order: "input" followed by "actions"
• Using TextBox
  • Using Placeholder
  • No "Copy" or "Edit" needed and we have #119
• Using Button to display browsers: simplifies UI (transparent) and Click handling!

[!IMPORTANT] Commented keybindings and number-watching keys

Ruleset Manager

Ruleset editor window

Timed browser

[Jay-o-Way]

@niels9001 🔝 Look what I made! 😁

[Jay-o-Way]

Keyboard accessible: includes https://github.com/U-C-S/Hurl/discussions/79

[U-C-S]

I will take a look at this, later this week or next week most likely.

[riotrah]

Not that anyone asked, but thought I'd share my aesthetic 2 cents.

fwiw I personally really do not like Mica, so I'm hoping this PR (if it's used ultimately, and in general with this project otherwise) doesn't force it. I actually prefer the un-colored (sorta light grey/white-ish in light mode, dark grey in dark) background that some windows UI surfaces have, over Mica, with Acrylic above either. All three options might be nice actually if users want it and it's not hard to implement (meaning, add the uncolored one, as there's already Mica/Acrylic).

Apart from colors tho, I like everything else about your version. The consistency with the rest of Win11's design language really makes Hurl feel like a part of windows, which feels appropriate given it's a power user utility app - one of my favorite things about modern third party mac apps is how well they gel with the rest of the OS. This version feels a lot like, say, the "Open with..." dialog, or even the start menu, etc.

The only thing would be that I'd expect (going by Start Menu) that context menus and tooltips would have drop shadows. And something about the corner rounding and padding of the tooltip seems off.

[riotrah]

And if you guys were willing, I wanted to derail this thread for second to ask how I can learn more about the various different ways of making windows apps, eg what is the difference/tradeoffs between WPF, WinUI, etc?

[niels9001]

And if you guys were willing, I wanted to derail this thread for second to ask how I can learn more about the various different ways of making windows apps, eg what is the difference/tradeoffs between WPF, WinUI, etc?

There was a recent Build session about that: https://youtu.be/ZjaL3pL-OuM?si=ZCPdRGEDB6JcQ6X6

[Jay-o-Way]

Hi @riotrah, thank you for your message!

Yeah, the background issue feels like a personal opinion. I don't mind it. But, of course, you may have yours 🙂 I will leave it to @U-C-S if he wants to use it or something else. Actually, with the current version of WPF-UI, there is a bug where, after a while, the mica effect fails. Even on Windows 11. So, you might just like that, haha!

Thank you so much for the compliment! I'm really proud of it! 😇 I even have a few more (small) things waiting for a next PR.

About the little UI bugs you mention: that's a WPF-UI issue. From what I can tell it is "just" a third-party framework and personally I am not a fan of that. I would rather use either WinUI c.q. Microsoft WPF. But that's also a choice @U-C-S has to make. And it requires quite a big re-write.

[U-C-S]

I would rather use either WinUI

I really want to, But it's so hard/confusing to get a unpackaged app running properly and reliably, and the install sizes are huge (like ranging from 40MB to 180MB). Wouldn't be much Big rewrite either, I have done it thrice (including a UWP port) already at this point and gave up during publishing. But the preview or upcoming updates for both WPF and WinAppSDK/WinUI looks really promising.

Looking into your PR currently @Jay-o-Way

[U-C-S]

Tried it out locally.

I like couple of ideas here like the bottom bar where you put the Rules, settings btns... I personally do not like the way the looks of WinUI TextBox, But I want to do something like current Edit URL button which onClick gets swapped with TextBox control, which I feel is best of both our ideas. What do you think ?

I will keep updating this comment as I use it.

[Jay-o-Way]

I personally do not like the way the looks of WinUI TextBox

Is there something specific? This control has a lot of important benefits with accessibility: Tabstop, in-place-editing, built-in "clear" button and context-menu, screen reader support... People that use non-standard input devices really need this. Users want things to be as fast and easy as possible.

Maybe I could set the default background to Transparent - to make it even more subtle. That'll leave the hover and focus colors intact.

Sneak preview

[Jay-o-Way]

P.S. next branch is already work in progress: https://github.com/Jay-o-Way/Hurl/tree/UI-improvements

[U-C-S]

Maybe I could set the default background to Transparent - to make it even more subtle

It looks much better actually.

• Also wanting to use a btn changing into TextBox onClick, because Editing URL from within Hurl window which I believe is a rare interaction and Clear current URL could be a btn itself beside it.

Additionally, continue with my thoughts on changes you made,

• continuing from above statement about the URL TextBox being a btn, I prefer it would be on the bottom of the browsers grid component. Just so it's not the main focus but another feature.
• like the changes made for Timed default and ruleset manager windows overall
• but not with the Ruleset Editor window, and Type and Window card specifically. The 'Add' btn feels separate from the function meant by the card itself. Would include btn inside the card itself
• Also the info btn, which is missing from above point, is just a small explanation flyout I want to include onClick about different Types of rules.

I want to continue further (including about the change I made recently: https://github.com/U-C-S/Hurl/commit/13e3d4d79d65e388e952b570c91392ddc3c5720b#commitcomment-143173677), but Maybe at this point, it would be a better idea, to have it in a new discussion conversation instead because it feels UI design discussions are spread out in lots of places.

Typing this from mobile and from memory...:)

[Jay-o-Way]

@U-C-S I Updated TextBox and Add button. I know the Textbox is an open discussion but is there anything actually blocking this? Thanks.

[U-C-S]

Sorry, didn't notice this comment

anything actually blocking this?

PR tweaks lot of things, which is fine, but there are changes I don't want or have a prior focused discussion... which would make a quite a list. So probably I think, the better idea would be breaking this PR into multiple small PRs where I have some I can merge straight away (like the code refactor stuff etc...), some I don't like to (removal of 2 app visual settings etc...) and some with discussion.

honestly I am not certain what's the better thing to do for a PR which changes lot of things. or Should I review the PR and just point out things I wouldn't want ?

[Jay-o-Way]

Okay @U-C-S I hear you. I had a few extra ideas I can use on the new PRs.

I just worry that multiple PRs will create merge conflicts between them, causing extra work when one is merged. Also, I saw you have a few different branches. Which one would be the best to use (as base or target) ?

[U-C-S]

multiple PRs will create merge conflicts between them, causing extra work

Yeah you are right. But don't know any alternative way we can do this, but more focused PRs are very sensible to keep track off for me as a maintainer.

Also, I saw you have a few different branches. Which one would be the best to use

main branch is fine....

[Jay-o-Way]

Yeah you are right. But don't know any alternative way we can do this, but more focused PRs are very sensible to keep track off for me as a maintainer.

I understand. (Not the first time I got that feedback 🫣)