No zenity, for the reason you mentioned.

It should be doable, adding an options group. We would have to pass more arguments to generic_gui_message for all messages, like:

• number of versions available (if one, don't show the options).
• each version text.

Kind of messy, so wondering it it's not nicer to have a separate GUI for tb_updater, included in the package. There is always an alpha release available, I believe. We could give the user the choice to install stable or alpha.

wondering it it's not nicer to have a separate GUI for tb_updater, included in the package

I don't mind either way.

proposed layout:

[x] likely stable | 4.0.3
[] likely alpha | 4.5a3

Yes | No [default]

Or something like that.

Maybe similar to this?

proposed command line interface:

/path/to/tool \
   "$type" "$TITLE" "$MSG" "$question" "$button" \
   --choice-default 1 \
   --choice-1-version "4.0.3" --choice-1-text "likely a still security supported and fine stable version" \
   --choice-1-version "4.0.3" --choice-1-text "might be a newer stable version" \
   --choice-3-version "4.5a3" choice-3-text "likely alpha version (name contains an 'a')" \
   --choice-4-...

Or something like that?

We could give the user the choice to install stable or alpha.

Yes. And a version list in general, since it's impossible to recommend the "best" one.

I think recommending the lowest version number by default could be best. Then chances are best it's a stable version and no alpha. Since it comes from the RecommendedTBBVersions file, it would also still be a perfectly security supported and save version. Those who wish to use higher version numbers or even alphas, could just pick to do so.

Maybe the same multiple choices feature could be used (with different values) for T138?

Maybe the same multiple choices feature could be used (with different values) for T138?

Was thinking on the same line. Will see.

What change can we expect from T161, in the number of versions available?

Dunno. In past with RecommendedTBBVersions maximum was ~6 or so. Best to have a good buffer to be able to scale up if needed.

Added a specific GUI for tb_updater. It's in msgcollector, for not findinf a better place.
https://github.com/troubadoour/msgcollector/commit/ae09f9c695401bcc8bcc54c0a46d3b81244b8fe7

It takes two new parameters: installed_version and online_versions.

The online versions are a comma separated list. The script returns the selected version text (as passed by update-torbrowser) in the options group.

All this is provisional can be modified to suit the bash script.

To test:

./tb_updater_gui info "Tor Browser Updater" "4.0.3" "Stable,Alpha1,Alpha2" "Message" "Question" yesno

It's very nice already! I am in process of porting tb-updater to it.

• Currently installed version cannot be copied.
• Online detected version cannot be copied.
• "Download confirmation" is currently hardcoded. It needs also some way to show "Installation Confirmation". (No it does not - can continue to use generic gui tool as is.)
• Can you please make the warning and error sign bigger as with generic gui tool?
• The window is a bit too short (or narrow, you tell me). Need to click the scroll down button 3 times. Command for testing (can be copies as is into Konsole etc.):

/usr/lib/msgcollector/tb_updater_gui \
   "warning" \
   "Tor Browser Updater (by Whonix developers)" \
   "4.5a3" \
   "4.5a3,4.0.3" \
   "<p>Looks like Tor Browser is already up to date.</p>

<p>Please close Tor Browser if you want to (re-)install!</p>

<p>If your currently installed version is:<blockquote>
   - higher: you are likely target of a downgrade attack, SAY NO NOW.<br></br>
   - equal : only proceed, if you want to create a new browser profile.<br></br>
   - lower : you should upgrade.</blockquote></p>

<p>YOUR BROWSER WILL BE KILLED.<br></br>
YOUR WHOLE BROWSER PROFILE INCLUDING BOOKMARKS AND PASSWORDS WILL GET REPLACED.</p>

<p>A backup of your old Tor Browser and settings will be created in your home folder.
<br></br>It is a good idea to delete old TBB backups once in a while if you are running low with disk space.</p>

<p><a href=https://www.whonix.org/wiki/Tor_Browser/Download_Confirmation_Screen>Learn more about this Download Confirmation Screen.</a></p>" \
   "Download now?" \
   "yesno"

• When the window gets closed, can you please also echo 65536 (same as click "no") cancel so the script can detect this and abort?

Currently installed version cannot be copied.

Fixed.

Online detected version cannot be copied.

Not doable. The text is part of the button and do not accept TextSelectableByMouse

Can you please make the warning and error sign bigger as with generic gui tool?

Here, it's the same size as Confirm Open, for example (64x64).

The window is a bit too short (or narrow, you tell me).

Fixed. Made the window slightly wider so that when link confirmation pops, the vertical borders are separated.

When the window gets closed, can you please also echo 65536 (same as click "no") cancel so the script can detect this and abort?

Done. generic_gui_message is updated with this too.

Can you please make the warning and error sign bigger as with generic gui tool?

Here, it's the same size as Confirm Open, for example (64x64).

Here is how tb updater gui is looking for me:

{F38}

Same for me. The icon is the same size as the generic_gui_message and msgdispacher_dispatch_x.

Didn't you in increase to 128x128 or so in past? Could you increase it again please?

Yes I did, and reverted. Do we want 128x128 for warning and error in all the GUIs?

Do we want 128x128 for warning and error in all the GUIs?

Good question. I don't know. No one suggested that yet. And it didn't occur to me. Dunno what's best so I am open for suggestions.

On a second thought, we also need this for msgdispatch_x. Otherwise tb updater gui would show a big one (Download confirmation) and later msgdispatch_x would show a small one (Installation confirmation). So probably best to increase it for all?

May be leave generic_gui_message with smaller icons? The messages like Confirm Open or Not root are not critical. Or we could add an argument icon_size, but that would be a lot of bash updates.

In T149#2521, @troubadour wrote:

May be leave generic_gui_message with smaller icons?

Yeah, good idea.

The messages like Confirm Open or Not root are not critical.

Indeed.

Or we could add an argument icon_size, but that would be a lot of bash updates.

Yes. Probably not required at this time.

but that would be a lot of bash updates.

(As a side note: Wouldn't be if it defaulted if something, i.e. 64 or so.)

OK. Pushed the change in msgdispatch_x and tp_updater_gui. A small issue. Because of the layout, the Online versions option group is shifted down, below the bottom of the icon.

Next step would be T138. Not sure yet how to integrate it. Same window, an extra line Select language with a drop-down list? A separate GUI? Or perhaps from the desktop environment installed language?

In T149#2533, @troubadour wrote:

OK. Pushed the change in msgdispatch_x and tp_updater_gui. A small issue. Because of the layout, the Online versions option group is shifted down, below the bottom of the icon.

I see. Can this be fixed?

Next step would be T138. Not sure yet how to integrate it. Same window, an extra line Select language with a drop-down list? A separate GUI? Or perhaps from the desktop environment installed language?

That is somewhat T72, which you partially already implemented in "whonix-setup-wizard locale_settings". When we start that (using xinit) (perhaps in Whonix 11?), then system language gets set. tb-updater could use the same language. The question is, how could tb-updater figure out what was set in KDE (or..)?

In T149#2535, @Patrick wrote:

The question is, how could tb-updater figure out what was set in KDE (or..)?

Answered my own question here:
https://phabricator.whonix.org/T72#2538

In T149#2535, @Patrick wrote:

In T149#2533, @troubadour wrote:

OK. Pushed the change in msgdispatch_x and tp_updater_gui. A small issue. Because of the layout, the Online versions option group is shifted down, below the bottom of the icon.

I see. Can this be fixed?

Yes :) https://github.com/troubadoour/msgcollector/commit/e2cdfa3cc8416260d3fa56bbd888dd46e91d4416

Nice. Merged and tested. Closeable?

Yes.