Open og-mrk opened 4 months ago
I was thinking about this as well. I think making the background a bit lighter in dark mode.
This is something I might take a crack at as well. When it comes to design it can be user specific. If we have a good theme config file we can have multiple options.
I was thinking about this as well. I think making the background a bit lighter in dark mode.
The change in theme's colors can be tweaked.. but this isn't really my goal.
- Comic Sans is one of my most hated fonts. That won't get merged.
Used it for testing, found it quite funny to use (for the memes of course π), as well as how my changes actually worked! (First time playing with WPF Framework).. but still, it isn't consistent across all "elements" (as seen in the tabs and buttons of the screenshot)
- Dark Black is sub-optimal I a darker grey would be much easier on the eyes.
- Optimize the glow effects and contrast.
Both contrast & colors can be improved, and the glow effect is an interesting case.. as it looks like WPF currently (from what I see) renders the whole window on every change, so there's some work to be done.. really stretching the limits of a script here π
This is something I might take a crack at as well. When it comes to design it can be user specific. If we have a good theme config file we can have multiple options.
The theming overhaul should hopefully improve on this, as currently the testing process is a bit slow (maybe have winutil dynamicly load config files while it's running?)
I'll be aiming for a more "you customize anything and everything about the program.. if you choose so" kind of approach, I always enjoy games & programs that gives me greater control of how things look/feel (choose how fast or slow animations play, how big or small things look across the app, or even specific elements, and so on..
Also, it's better to have a "parent/child" relationship when styling, where the child follows the parent's styles.. only overriding it when the child element has its own styling set.
I really like the Idea @og-mrk π
"overhaul" can be a big word, There are many things to consider when designing an Application, I will list some of my thaughts i gathered lately in form of notes about the UI/UX, which i also had planned to give a look at some day:
At first I would suggest making simplified & cleaned up color pallets. assign colors to certain elements ...
After that I would suggest looking at the toolbox and think about the layouting of everything and anything, having accessability in mind. For example; Users sometimes don't see the undo button for the tweaks because of the many tweaks added in time, There were opened some issues on undoing stuff they've done. (Some tried running the undo script by pasting it into the console). So sticky elements would be a great change this "issue".
Some times the "action" buttons are on the top, some times on the bottom, sometimes elsewhere, sometimes clicking a button does stuff
double clicking in WinUtil maximizes/windowed (idk the second term) the application. Some times that can be annoying like when accidentally checking an application and unchecking it, or trying to edit in the search bar and accidentally double clicking.
Another Thing would be changing the Cursor's icon because some elements change it when they should, other do it when they shouldn't, others don't do it when they should.
Regarding the WPF Framework and the UI elements. Technically it supports updating the elements on the fly while running. Played around with this while I explored the idea of pushing theme changes on the fly while the tool was running, but got annoyed and eventually stopped because of the inconsistency in regards to the way the elements are set up (some habe element names/IDs some don't etc.) and loaded into the $sync variable for easy referencing. I think implementing some kind of inheritance, a simplified color palled and a consistent way of creating, naming and referencing the elements would go a long way to creating an UI that can easily be updated/changed and I think it's worth it in the long run even though it's a lot of work :)
themes.json
file.Get-TabXaml
Code to make it more maintainable.themes.json
file.Get-TabXaml
Function.~ Fixed in commit https://github.com/og-mrk/winutil/commit/df7b27a583c2d3c57afd2c8505fe64858823521aMaybe also take a look at the following thread for an example on how to implement dynamic theming with .net WPF all be it in c# Maybe it helps adapting some of the same principles https://stackoverflow.com/questions/72672788/how-create-dynamic-themes-in-wpf-applications
Maybe also take a look at the following thread for an example on how to implement dynamic theming with .net WPF all be it in c# Maybe it helps adapting some of the same principles https://stackoverflow.com/questions/72672788/how-create-dynamic-themes-in-wpf-applications
Thanks @Marterich , will look into it and see how I could implement it.
@ChrisTitusTech @Marterich @MyDrift-user Made the first PR that addresses WinUtil UI. It isn't much.. but it's a start nonetheless, and I'd be happy to hear what you guys think about the changes, any constructive criticism & feedback are welcomed π
you can test these changes out by doing gh pr checkout 2274
in your locally cloned WinUtil Repo (if you have GitHub-CLI installed), or by cloning my Fork, or any other way you might like π
Here are some additional suggestion on assigning colors:
EDIT:
You sometimes get a small visual hint on where you are currently at when moving through WinUtil, but because of the styles it is very hard to see. If you try it out you'll see what I mean.
EDIT 2:
EDIT 3 (# 2252):
Enable DPI Awareness
Handle DPI Changes in XAML:
Ensure DPI-Aware Layouts:
@og-mrk At the moment the Install Tab of Winutil doesn't really have any concept of groups that overflow into the next row if there are too many entries, but the row positioning of an entry is statically set when compiling. This can easily be visualized by searching for "Windows Terminal" by example and seeing that the Application is shown in another row than the heading. I experimented with this a bit when I first changed the logic to hide the applications that don't match the search, but I wasn't able to find a solution in the time I was willing to invest. Maybe this is something you (or anyone else) want to put on the backlog, take a look and see if you have any ideas
I experimented with this a bit when I first changed the logic to hide the applications that don't match the search, but I wasn't able to find a solution in the time I was willing to invest. Maybe this is something you (or anyone else) want to put on the backlog, take a look and see if you have any ideas
I once used "WrapPanel" for something similar. That seemed to work and fixed some other "issues". That would be a whole other way to layout the applications and i think WinUtil even used that once. Idk if that would be of use but just wanted to throw this option in.
Fix this you plonker. I CAN'T USE WINUTIL. ADD SOME MINIMUM WIDTH AND HEIGHT!!!!!!!!!!!!
WARNING -- THIS IS NO LINE THIS IS WINUTIL -- WARNING
MAKE THIS BLACK
Some Toggles in the tweaks section are designed for use in Windows 11 Only.. making these toggles Disabled or not visible when the Windows Version is not what's expected by the toggle.
This way, we could have Windows 10 Specific Toggles, and Windows 11 Specific Toggles without any issues rising from it, like a certain toggle not working on my Windows 10 machine, when it's designed for Windows 11 in mind, and so on...
Discussion to Issue linking doesn't seem to be supported by GitHub at the moment.. so I'll provide a link for it over here.
This issue was marked as stale because it has been inactive for 7 days
Adding this comment to keep issue open, please ignore it...
I like winutil; nevertheless, I agree that the UI of winutil looks amateurish.
I raised a few issues about inconsistencies in font type, ambiguities, and spelling mistakes in the UI, but my issues were completely ignored. The UI for the page on MinWin looks like it has been written by a novice typist. My issues were closed without prior notice and without explanation, so further discussion was not possible, and correction were not made.
The developers have made the script work (probably), and now they need to make the UI look good. The developers need to consider artwork (meaning page layout), and listen to users who can see difficulties with the UI.
@og-mrk Future UI enhancement suggestion: add a status bar (Label or TextBlock) in the GUI to display the latest action performed by Winutil. Additionally, include a dropdown button beside it to expand a history log of all executed commands. Similar to the implementation of the Progress Bar with Text in #2466, we can fill and update this history log. Create a helper function to wrap and replace the standard Write-Host calls, appending each new log message and action to the UI log as well as printing it. Modify the compile script to use this new wrapper instead of the default Write-Host. Optionally, this log can also be written to disk from the helper function. This enhancement would allow us to hide the PowerShell window, leaving only the GUI visible at runtime.
@og-mrk Future UI enhancement suggestion: add a status bar (Label or TextBlock) in the GUI to display the latest action performed by Winutil.
Implementation wise, we should do it by updating a "global" variable, which on its value change will update the UI.. or set its value by calling a function, which does everyhting to update/signal UI appropriately.
We could it through a more sophisticated way, by creating a strict protocol that's followed by any code in WinUtil which want to send information, this way.. there'll be a model of call a function -> creates specific data stream according to function input -> something that runs this data (engine) which'll display things in UI.
.. this's entirely implementation wise, and really the main idea should be as simple as getting what's displayed from terminal, and just show it in a TextBox.
Additionally, include a dropdown button beside it to expand a history log of all executed commands. Similar to the implementation of the Progress Bar with Text in #2466, we can fill and update this history log. Create a helper function to wrap and replace the standard Write-Host calls, appending each new log message and action to the UI log as well as printing it. Modify the compile script to use this new wrapper instead of the default Write-Host. Optionally, this log can also be written to disk from the helper function. This enhancement would allow us to hide the PowerShell window, leaving only the GUI visible at runtime.
.. this's indeed an interesting approach, cool idea @Marterich
This issue was marked as stale because it has been inactive for 7 days
Adding this comment to keep issue open, please ignore it...
This issue was marked as stale because it has been inactive for 7 days
what about every install section in a separate page . Like i saw 350 apps in one single page if you plan to go to 500 you need a separate page for each type. (browsers, windows apps, utility). you can implement some python or c++ lightweight gui for that
What this announcement all about
Before I tell what this announcement is all about.. I should make a quick disclaimer by saying:
This is by No Means an Official Announcement for WinUtil! It's just a Volunteer, author of Issue Ticket, who likes to share his progress and idea(s) to others
With that being said, lets continue with this Un-Official Announcement...
UI Changes
For now, I can't say much on how it'll change other then the things I've done, because I'm trying to understand the WPF .NET Framework and how to utilize its features as much as I can.. So I'll leave you with this cursed image π
Comic Sans & Mono-Spaced Fonts never looked this good before π You also may have noticed the Text is bigger then usual.. because it very much is! Will see what I can improve with this side, as it's not as consistent as I like it to be
UX Changes
UX (aka. User Experience) is how well designed your UI is, currently WinUtil.. to put it lightly, suffers from lack of consistence spacing (padding/margins), lack of creativity into UI looks (e.g. it's very empty in its design choices.. noticed this in most programmer-first projects, no offense but designers are better at.. designing π ), and it just.. it can be improved by a lot, so.. what's the plan?
Well.. I'm no designer myself, so I'll try my best to come-up with a good design (even if implementing it will be difficult), and also by creating this Issue Ticket, it might (even if it's 1 out of 1000 odds) grab the attention of a Good Designer in the WinUtil Community, if you know anything about app design, and have used this tool before.. please consider sharing your ideas & thoughts in a comment, it'll be much appreciated π
Theming Overhaul
Changing the Theming of WinUtil is quite a basic process:
theme.json
File.Compile.ps1 -Run
in PowerShell Admin (or runCompile.ps1
then runwinutil.ps1
in PowerShell Admin).But the file has.. it has too many options! it would be nice to have hierarchy theming (
Button
Json Object hasOnHoverColor
,BackgroundColor
and so on..), and having default values for every field, so you don't have to fill every single field with a specific value.For now, I'll be covering the above 2 cases, don't know if it'll be difficult to implement, as I haven't started and will likely re-factor my implementation a couple of times, as I want it to be easily maintainable + well designed/thought of.
Final Notes
If you come this far into the Issue Ticket, I'm glad you've read my relatively small announcement till the end (again.. Un-Official Announcement π), first time doing such a thing and I don't know if it acceptable to do in here (in WinUtil's Issues).. nonetheless it'll be interesting to see how well it goes π
If you like what you see, give it a π and share your thoughts down below βοΈ, it'll be of good help to me while working on this π