The reason for this seems to be that the Italian translated string contains a slash wich fltk will interpret as submenu. With read/write will be a read menuitem with a submenu containing write menu item. When write is selected tlclient crashes.
Fixed in commit 29951
Reopened for further discussions. Menu items have several special characters as; "The characters "&", "/", "\", and "_" are treated as special characters in the label string. The "&" character specifies that the following character is an accelerator and will be underlined. The "\" character is used to escape the next character in the string. Labels starting with the "_" character cause a divider to be placed after that menu item." We need to handle those for translations so we don't get into this kind of troubles in future. Possible solution is to subclass menu and escape string before added disabling the markup at all.
The actual crash is the following line: DrivesAdvancedWindow::inputs_to_browser (this=0x98ca90) at tlclient_advanced_options.cc:883 where export_modes_strings[data->mode] is null..
One issue here is if we should have "Read-Write" or "Read/Write". Proof by Google doesn't work as they strip delimiters when performing a search. Grepping the transations on my local machine favours Read/Write heavily. But it is also used in the meaning "Read OR Write". Gnome seems to prefer to avoid the ambiguity altogether by specifying "Read and Write" where relevant.
tlclient.bin fixed in r30010. It has these menus: - The OS X application menu - Smart card selector - Local drive mode - Context menu key
TigerVNC fixed in 30017. It has the context menu, and the context menu key configuration in options.
Changed the phrasing to "Read and Write" in r30018.
Fl_Menu_ is even more broken than initial investigation showed. Need to look further into this.
New attempt for tlclient.bin in r30031.
vncviewer updated again in r30036.
Documentation updated in r30037.
Regarding the choice of using "Read and Write" we should probably consistently be using it in the UI. Export configuration has an optionstring "Not exported / Read Only / Read-Write" which probably should be "Not exported / Read Only / Read and Write"
(In reply to comment #12) > Regarding the choice of using "Read and Write" we should probably consistently > be using it in the UI. > > Export configuration has an optionstring "Not exported / Read Only / > Read-Write" which probably should be "Not exported / Read Only / Read and > Write" This was a false positive, our pot still had the string but no code was referencing it...
Verified using client build 4726. - Tested the escaping of string with special characters - Verified the rename of read/write to read and write Looks good.