Merge ~xnox/software-properties:clickable-pro into software-properties:ubuntu/master
Status: | Needs review |
---|---|
Proposed branch: | ~xnox/software-properties:clickable-pro |
Merge into: | software-properties:ubuntu/master |
Diff against target: |
48 lines (+10/-2) 2 files modified
data/gtkbuilder/dialog-ua-attach.ui (+1/-1) softwareproperties/gtk/DialogUaAttach.py (+9/-1) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Nathan Teodosio (community) | Disapprove | ||
Ubuntu Core Development Team | Pending | ||
Review via email: mp+443188@code.launchpad.net |
Commit message
dialog-ua-attach: attempt to make /pro/attach URL clickable
Just setting markup on the child label of the GtkRadioButton is not enough, as the URI does not get hover effect like the other urls (mouse pointer changing into a finger) and the URI itself is not clickable GTK style.
Ideally, I want clicking radio button to change radio button state, clicking "Enter code on" to do nothing, and only ubuntu.
This is so far best I could do, but it would be nice if we could wire up a normal activate-link signals through to gtkradiobutton.
Note splitting gtkradiobutton into like hbox of empty radiobutton + gtklabel might work, but likely break a11y / screen readers.
The root of the problem might be motivated by the whole width of the screen being allocated as selection area for the button. So if a URL is present, the question is: Does clicking the URL launch the URL or activate the radio button, or both?
Your workaround answers "both" to that question, which I guess is fine — I wonder how designers would answer —, but introduces a side effect of having a browser window or tab open for each time the radio button is selected, also when keyboard navigation is used; I think this is too high a price to pay. One could use Pango Layout's get_pixel_size to get the label width, get the x position of the mouse click and then decide if the click was on the link or not, but it seems too much work and maybe it cannot be made accurate (because maybe there is no way to get the x coordinates interval the link occupies), so I would rather do the hbox and possibly confuse screen readers.
Now, the hbox workaround would introduce another effect: the button selection area would no longer be {window width, radio button icon height} but {radio button icon width, radio button icon height}. So for consistency sake we would do the same for the other radio button too.
What do you think?