Created attachment 768649 [details] ping page display Description of problem: In the ping page, it should display the current input digital when there is no more space to display the whole address. Version-Release number of selected component (if applicable): rhev-hypervisor6-6.5-20130222.0.auto1707.el6.iso ovirt-node-3.0.0-1.999.20130701111251git99aadc6.el6.noarch How reproducible: 100% Steps to Reproduce: 1. Clean install the rhev-hypervisor6-6.5. 2. Configure the network with ipv6 auto mode. 3. Input the ipv6 address which you want to ping in ping page. Ping a remote host Address: 3ef1:b8:1:0:5054:ff:fe26:2052 Actual results: In step3, when you input the last 3 digital, you can see whether you input it or not because it can not display. Expected results: In step3, you can see the digital which you currently input. Additional info:
And there is also the same issue in all the text box.
It should be better to reorganize the length of all the text box especially those related to ipv6 address. Cause in ipv6, it will need more space to display it.
Fabian, you were looking at a way to make text boxes scroll, right?
Yes, I'll be looking into this.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Ryan, can you take a look at this. It would probably help for 6.5 if the entry always shows the content around the cursor - and this is currently not happening. I wonder if this is a urwid problem or if we miss to set some falgs when building the UI.
There doesn't seem to be an easy way to do this in urwid, so I changed the render method for EditWithChars to be smarter when the length of the input is longer than the length of the field. On the plus side, we can see characters which are being typed. On the downside, I haven't found a way to decouple urwid's cursor position and from urwid.Edit.edit_pos -- trying to make it behave like a normal text box which can be scrolled from side to side with arrow keys with a cursor position which is meaningful. Setting the cursor position necessarily updates edit_pos. While this patch resolves the current problem, it doesn't solve the long-term problem of making the Entry field, but that may be doable for 6.6
(In reply to Ryan Barry from comment #11) > There doesn't seem to be an easy way to do this in urwid, so I changed the > render method for EditWithChars to be smarter when the length of the input > is longer than the length of the field. > > On the plus side, we can see characters which are being typed. > > On the downside, I haven't found a way to decouple urwid's cursor position > and from urwid.Edit.edit_pos -- trying to make it behave like a normal text > box which can be scrolled from side to side with arrow keys with a cursor > position which is meaningful. Setting the cursor position necessarily > updates edit_pos. > > While this patch resolves the current problem, it doesn't solve the > long-term problem of making the Entry field, but that may be doable for 6.6 Yep. We should definetly target scrolling within the Entry field for 6.6. We can possibly achieve this by inheriting more from the original Entry class.
The original urwid entry class doesn't appear to support this either. It adds an additional line for entry below for overflow text, but I haven't experimented with it much.
This bug is currently attached to errata RHBA-2013:15277. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thank you for your help.
According to comment#16, this issue is not fixed completely, so change the status from ON_QA to ASSINED.
We've got a workaround but then the input fields are not underlined anymore.
If I'm lucky, I'll get a chance to look at this tomorrow, but it may not be feasible to correct during this development cycle (if it's too complex or simply takes too much time with the other issues and a short deadline). If it can't be resolved, and the choices are either: input fields are no longer underlined (potentially with a different background color to emphasize that they're editable) input fields cannot be scrolled to the left without deleting characters Which would be preferable?
The following snippet can probably help to solve this for all underlined fields: https://gist.github.com/wardi/8337153
I'll experiment with that snippet, though it currently has the same problem as comment #13 -- adding additional rows is problematic.
*** Bug 895005 has been marked as a duplicate of this bug. ***
Basic functionality is working, but exception when you press <END> in a text field where the contents are exceeding the length of the widget.
(In reply to Fabian Deutsch from comment #27) > Basic functionality is working, but exception when you press <END> in a text > field where the contents are exceeding the length of the widget. This strongly appears to be a bug in urwid, but I'll investigate.
Patch updated, though I have no idea why urwid has that particular assertion, since no other problems come up if it's removed.
Test version: rhev-hypervisor6-6.6-20141212.0.iso ovirt-node-3.1.0-0.34.20141210git0c9c493.el6.noarch Test steps: 1. Clean install rhev-hypervisor6-6.6-20141212.0.iso. 2. Input long character in text field such as Hostname, DNS server, RHN Registration page. Test result: 1. During input long character, it shows the current input character. 2. After save the configuration, it shows the long character starts at the first one. And the curse can be moved to the end to modify it. So this issue is fixed in rhev-hypervisor6-6.6-20141212.0.iso. Change the status from ON_QA to Verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0160.html