Writing [a.lock().unwrap().b.lock().unwrap()] sucks, so these are
some macros that are for common situations. This commit also has
a [sed] replace on all previous code that _could_ have been a macro,
which they all are now.
Hopefully nothing breaks :D
Keyboard shortcuts [Left] & [Right] were clobbering the
[TextEdit] left/right movement, so they are now [Z/X].
The shortcuts also look to make sure a TextEdit isn't
in focus so that [S/R/Z/X] can actually be typed.
P2Pool/XMRig now make sure the path ends with an [ACCEPTABLE_*]
value (e.g: P2pool, P2POOL) before enabling the [Start] UI.
The entire codebase is now littered with [debug!()] messages.
Thankfully [log] has 0 cost if you aren't using them, so regular
users won't have a runtime penalty unless they specify RUST_LOG=debug.
This commit takes care of correctly starting [sudo] with XMRig as
a command argument. The frontend [restart_*] function is also
implemented. In XMRig's case, the threads will sleep [3/5 seconds]
before [starting/restarting] so that [sudo] has time to open its
STDIN. This prevents premature inputs and outputting the password
to the STDOUT.
Lots of stuff in this commit:
1. Implement [Start/Stop/Restart] and make it not possible for
the GUI to interact with that UI if [Helper] is doing stuff.
This prevents the obviously bad situation where [Helper] is in
the middle of spawning P2Pool, but the user is still allowed to
start it again, which would spawn another P2Pool. The main GUI
matches on the state and disables the appropriate UI so the
user can't do this.
2. Sync P2Pool's [Priv] and [Pub] output so that the GUI thread
is only rendering it once a second. All of Gupax also refreshes
at least once a second now as well.
3. Match the [ProcessState] with some colors in the GUI
4. GUI thread no longer directly starts/stops/restarts a process.
It will call a function in [Helper] that acts as a proxy.
5. The tokio [async_spawn_p2pool_watchdog()] function that was
a clone of the PTY version (but had async stuff) and all of the
related functions like the async STDOUT/STDERR reader is now
completely gone. It doesn't make sense to write the same code
twice, both [Simple] and [Advanced] will have a PTY, only
difference being the [Simple] UI won't have an input box.
6. P2Pool's exit code is now examined, either success or failure
7. Output was moved into it's own [Arc<Mutex>]. This allows for
more efficient writing/reading since before I had to lock all of
[Helper], which caused some noticable deadlocks in the GUI.
8. New [tab] field in [State<Gupax>], and GUI option to select
the tab that Gupax will start on.
A [must_resize] and [ctx.is_pointer_over_area()] is now used to
indicate we need a resizing. This makes it so when a user is
resizing the width of Gupax, the heavy [init_text_styles()] func
will only get called once when the user hovers over the GUI.
The button size is also now set in that function so it doesn't
have to be called in every separate tab.
Define a strict list [&str; 4] of valid path endings for p2pool/xmrig.
This prevents users (for some reason) inputting a path to some
other (maybe very important) file which Gupax would have completely
overridden with the update binary. Windows paths end with [.exe].
[og: State] is now completely wrapped in an [Arc<Mutex>] so that
when the update is done, it can [.lock()] the CURRENT runtime
settings of the user and save to [gupax.toml] instead of using an
old copy that was given to it at the beginning of the thread.
In practice, this means users can change settings around during
an update and the update finishing and saving to disk won't be
using their old settings, but the current ones. Wrapping all of
[og: State] within in [Arc<Mutex>] might be overkill compared to
message channels but [State] really is just a few [bool]'s, [u*],
and small [String]'s, so it's not much data.
To bypass a deadlock when comparing [og == state] every frame,
[og]'s struct fields get cloned every frame into separate
variables, then it gets compared. This is also pretty stupid, but
again, the data being cloned is so tiny that it doesn't seem to
slow anything down.
