multiple choices support in generic_gui_message

[phabricator-migrator]

Information

ID: 149
PHID: PHID-TASK-cntjqvkwys4i5hhnvm7a
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

I am wondering how T130 could be solved in the long run due to the absence of a stable version format.

Maybe it’s best to provide the user with a multiple choice drop down menu, where they can choose the version. Could be added to tb-updater’s download verification screen*.

Would it be doable to write a multiple choice feature to generic_gui_message? Or do you have any other suggestions? @troubadour

Otherwise I could try to fall back to a zenity multiple choice solution, but that would introduce another screen and would be kinda ugly.

*(Looking similar to this.)

Comments

---

troubadour

2015-02-08 16:36:04 UTC

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.

---

Patrick

2015-02-09 08:56:03 UTC

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.

---

Patrick

2015-02-09 15:40:32 UTC

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

---

troubadour

2015-02-10 21:06:56 UTC

Maybe the same multiple choices feature could be used (with different values) for T138?
Was thinking on the same line. Will see.

---

troubadour

2015-02-19 23:26:12 UTC

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

---

Patrick

2015-02-20 09:20:06 UTC

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

---

troubadour

2015-02-21 19:12:50 UTC

Added a specific GUI for tb_updater. It’s in msgcollector, for not findinf a better place.
+ tb_updater_gui · troubadoour/msgcollector@ae09f9c · GitHub

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

---

Patrick

2015-02-22 12:47:21 UTC

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"

---

Patrick

2015-02-22 12:50:58 UTC

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

---

troubadour

2015-02-22 20:44:06 UTC

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.

---

Patrick

2015-02-23 12:29:56 UTC

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}

---

troubadour

2015-02-23 19:28:17 UTC

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

---

Patrick

2015-02-23 19:36:00 UTC

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

---

troubadour

2015-02-23 20:15:57 UTC

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

---

Patrick

2015-02-23 20:19:13 UTC

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.

---

Patrick

2015-02-23 20:21:46 UTC

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?

---

troubadour

2015-02-23 20:28:35 UTC

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.

---

Patrick

2015-02-23 20:40:14 UTC

! 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.)

---

troubadour

2015-02-23 21:03:26 UTC

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?

---

Patrick

2015-02-23 21:27:13 UTC

! 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…)?

---

Patrick

2015-02-23 22:02:02 UTC

! 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

---

troubadour

2015-02-26 21:07:56 UTC

! 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 layout · troubadoour/msgcollector@e2cdfa3 · GitHub

---

Patrick

2015-02-26 21:22:27 UTC

Nice. Merged and tested. Closeable?

---

troubadour

2015-02-26 21:23:18 UTC

Yes.