The terminal version would continue to run dialog. When X is available, it would use gdialog by default [+ option to use dialog instead].
You can test how gdialog looks by copying and pasting this example code.
gdialog --cancel-label Exit --title whonix_repository --menu 'Automatically install updates from the Whonix team?
Whonix News (via whonixcheck) will notify you of available updates.
When you run
apt-get dist-upgrade
updates from the Whonix team will be AUTOMATICALLY downloaded and installed, along with updates from the Debian team. Please read https://whonix.org/wiki/Trust to understand the risks.
You can always start the Whonix Repository Tool again by running:
sudo whonix_repository
' 100 120 20 1 'Yes. Automatically install updates from the Whonix team.' 2 'No. I will manually update from source code.'
(for comparison: drop the “g” or sudo whonix_repository)
I haven’t looked too throughly into it yet, but I think it would be doable with relatively low effort, because those tools are compatible by syntax(? to be researched more throughly].
The question for now is… Do you like the graphics or do you prefer as is?
[quote=“Patrick, post:1, topic:631”]The terminal version would continue to run dialog. When X is available, it would use gdialog by default [+ option to use dialog instead].
You can test how gdialog looks by copying and pasting this example code.
gdialog --cancel-label Exit --title whonix_repository --menu 'Automatically install updates from the Whonix team?
Whonix News (via whonixcheck) will notify you of available updates.
When you run
apt-get dist-upgrade
updates from the Whonix team will be AUTOMATICALLY downloaded and installed, along with updates from the Debian team. Please read https://whonix.org/wiki/Trust to understand the risks.
You can always start the Whonix Repository Tool again by running:
sudo whonix_repository
' 100 120 20 1 'Yes. Automatically install updates from the Whonix team.' 2 'No. I will manually update from source code.'
(for comparison: drop the “g” or sudo whonix_repository)
I haven’t looked too throughly into it yet, but I think it would be doable with relatively low effort, because those tools are compatible by syntax(? to be researched more throughly].
The question for now is… Do you like the graphics or do you prefer as is?[/quote]
I think you mentioned that you used full screen for some of the dialogs. Using gdialog for whonixsetup shows the first two disclaimer dialogs from the top of my screen to the bottom and if there is any buttons they are not visable, but I can press enter to proceed.
The remainder operate as expected with drop down type lists and buttons and look very nice.
Yes, this can very likely be solved. This is what I wrote in the other thread.
whonixsetup's disclaimer is too big. The buttons are outside the visible area. I wanted to split them into more screens some day anyway (to make them work in the less-lines-by-default gnome-default-terminal).
I believe it’s a place where Qt could come in the picture.
It should be relatively easy to create a dialog with a couple radio buttons. The only difficulty I can foresee is returning the proper values (generic_gui_message style, only a little trickier).
It is tailored for whonix_repository, but I called it “generic-dialog” because it could be made versatile by passing messages and radio buttons text (or anything else, actually) from the calling script.
For the time being, it’s in /usr/lib/, for not finding a better place.
A port to gdialog would supposedly be very simple. Agreed, gdialog is not that pretty. Since there is not much positive feedback, we can as well leave it as is.
Maintaining dialog (for terminal users) as well as Qt would be quite a lot more effort.
Can you please look through all of the existing whonixsetup, whonix-repository menus? Then see if how much effort it would be?
I don’t know if I should take the time to do any bash related changes. Supposedly (g)dialog vs generic-dialog syntax would differ? And reimplementing (the features we need for Whonix) of dialog in Qt could also be quite some effort?
There are also quite some GUI specific tasks on the tracker:
Instead, I am still considering something different. Leaving whonixsetup / whonix_repository for CLI users as is. (Patches welcome.) And… Eventually reimplementing whonixsetup for GUI users. Have the GUI version be more usable and feature rich.
For example, I don’ think it’s worth going through the pain of creating a bridge wizard for CLI users. The effort/gain ratio is not that convincing. (Patches welcome.)
The greeter (https://github.com/Whonix/Whonix/issues/15) and the bridge wizard (https://github.com/Whonix/Whonix/issues/167) has highest priority for me on the gui front. Before I think about a pure python/Qt rewrite of whonixsetup (gui-only [while leaving the existing cli implementation as is]), I would like to see progress on these tickets. Especially on the bridge wizard, because I am still unclear on how to integrate it with whonixsetup.
Can you please look through all of the existing whonixsetup, whonix-repository menus? Then see if how much effort it would be?
I had a look into whonix-repository. Writing only a GUI is easy, but I’m sure you agree that we cannot pursue in that direction, that is calling a GUI from bash when X is running. “generic-gui-message” is OK, but it should remain an exception.
Instead, I am still considering something different. Leaving whonixsetup / whonix_repository for CLI users as is. (Patches welcome.) And... Eventually reimplementing whonixsetup for GUI users. Have the GUI version be more usable and feature rich.
Agreed on a GUI version, leaving the bash scripts for CLI users untouched.
It’s not your top priority, but since I was on it, I have started with whonix_repository.
It’s not complete. At the moment it reads the settings from “/root/.whonix.d/”, displays the GUI accordingly and prints the new user settings.
Can you review and tell if this approach looks sound? (use kdesudo to run the script.)
I had a look into whonix-repository. Writing only a GUI is easy, but I’m sure you agree that we cannot pursue in that direction, that is calling a GUI from bash when X is running. “generic-gui-message” is OK, but it should remain an exception.[/quote]
Yes, kinda messy.
Agreed on a GUI version, leaving the bash scripts for CLI users untouched.
It’s not your top priority, but since I was on it, I have started with whonix_repository.
It’s not complete. At the moment it reads the settings from “/root/.whonix.d/”, displays the GUI accordingly and prints the new user settings.
Can you review and tell if this approach looks sound? (use kdesudo to run the script.)[/quote]
Will answer here: