-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Metadata and GUI #244
Comments
And why not doing it with PHP ? You could have the wiki and the generator at the same place, and you could arrange easier your class / group |
Wow awesome news! I planned to make a GUI myself one day, as I did't think this might be a thing that you'd be interested in, (so I'm glad you're going to take care about it ;)) though my primary goal would be a little different. E.g. sometimes I just need to run one or two fuctions outside of my usual scenario presets and it's annoying to create a temporary preset or typing things on the command line, so I was thinking about a script that would list and display all available functions from modules and then I'd just select or click what I need and fire up an one-time run. Anyway, please consider these ideas/requests: GUI:
CODE:
Some of the ideas/requests should be easy, but I understand the others could be outside of scope of this project by its complexity, so no stress. :) I'll continue with my crazy ideas/requests in other V4 issues, as they're more related to them... |
@c-rilaun: That's basically what I meant by the last sentence. But I had in mind something JS-based, so it can be run on client side even without access to the internet. @r3incarnat0r: I feel like I should stress that I still want to keep it as simple as possible. :D
It's literally just two buttons - load and save. What would be the benefit of that?
I'm not sure I understand. Do you mean to completely hide all the tweaks which are not in the preset from GUI? Or in other words - limit the GUI only to the tweaks defined by the preset? In what cases can it be useful?
I guess you're talking about comment-based help. I have really strong feeling about that one, as I find it overly verbose and difficult to read. Function which modifies a single registry entry and is now on 4 lines would double in size. But the point about
My initial idea was to infer the controls from the params if we design the parametrization (#241) logically and consistently. I fear that any advanced control customization can go wrong and/or result in bloated code really fast.
Do you mean something like "If registry HKLM:\blabla\DisableSensors is set, mark checkbox for DisableSensors tweak as checked"? I don't think that's practical. The tweaks are evolving, so e.g.
Yeah, about that... do you think you can drop me a mail so I have a more direct contact with you? 👼 |
My intention is basically to add an ability to set a customized script (just by customizing preset and launcher) that can act like a common tweaking or whatever purpose application and could be served to user as a solution for some scenario (to just click checkboxes, fill textboxes and apply).
It might look verbose, but it's just key and text pairs, dunno how it could be shorter for the features it offers. Also I don't understand what do you mean by difficult to read, it is perfectly readable for me and the whole thing makes sense in general imho. It seems the difference between our opinions is basically you just want the code as short as possible and I don't care much about it. :D (More specifically I do care about the code lenght and efficiency, but I don't count comments as the code :D ).
|
I hope the GUI way won't replace the script way, will it? |
So your own version of SharpApp https://github.com/mirinsoft/sharpapp |
For quite some time, I have an idea for PowerShell-based WindowsForms GUI which would help people to create their own presets. The interface itself would be generated automatically based on the tweaks in supplied tweak libraries. For this purpose, every tweak would need some metadata, such as group. There were already some mentions in #229 and possibly earlier.
With the classic approach where every tweak is selfcontained in a single function and for every function, there is a counterpart which reverts the behavior, the GUI could be constructed pretty easily. If #241 gets implemented, it would be much harder. The structure of parameters would have to be homogenous and predictable, so the GUI-building logic could place appropriate blocks.
The GUI-generator code doesn't have to be as simple as the tweaks, so there may be even some introspection used and no metadata would be needed as we have most of the information somewhere anyway (group, function name, parameter names, allowed types or values etc.).
The idea is that it would look as follows:
Another approach would be to create the GUI as web-based application, completely outside of scope of this project.
The text was updated successfully, but these errors were encountered: