Pivot
  1. Pivot
  2. PIVOT-565

Use TextArea in default tooltip rather than Label

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: wtk
    • Labels:
      None

      Description

      This would allow callers to more easily specify tooltips that contain line breaks.

        Issue Links

          Activity

          Hide
          Greg Brown added a comment -

          This issue has already been resolved. See PIVOT-394. If you want wrapping text in a tooltip, you can simply use a TextArea as the tooltip's content.

          Show
          Greg Brown added a comment - This issue has already been resolved. See PIVOT-394 . If you want wrapping text in a tooltip, you can simply use a TextArea as the tooltip's content.
          Hide
          André Thieme added a comment -

          I am aware of PIVOT-394 and just thought that such a constructor would be
          very convenient. Nearly 100% of all tooltips will contain text. So a constructor
          accepting text makes sense. If this constructor would create a TextArea
          implicitly under the hood then this would not allow only for short single line
          Tooltips, but at the same time for multiline ones.

          Also this issue was about the setTooltipText method.
          Please reconsider if users really prefer

          TextArea ta = new TextArea();
          ta.setText("Hello\nWorld");
          new Tooltip(ta);

          over

          new Tooltip("Hello\nWorld");

          And how much already written code would break if a Tooltip had again
          a String constructor (additionally to the new Component one which totally
          makes sense)?

          Plus setTooltipText could stay as it is, just providing a TextArea
          under the hood.

          Show
          André Thieme added a comment - I am aware of PIVOT-394 and just thought that such a constructor would be very convenient. Nearly 100% of all tooltips will contain text. So a constructor accepting text makes sense. If this constructor would create a TextArea implicitly under the hood then this would not allow only for short single line Tooltips, but at the same time for multiline ones. Also this issue was about the setTooltipText method. Please reconsider if users really prefer TextArea ta = new TextArea(); ta.setText("Hello\nWorld"); new Tooltip(ta); over new Tooltip("Hello\nWorld"); And how much already written code would break if a Tooltip had again a String constructor (additionally to the new Component one which totally makes sense)? Plus setTooltipText could stay as it is, just providing a TextArea under the hood.
          Hide
          Greg Brown added a comment -

          When using setTooltipText(), a caller does not need to create the tooltip directly - it is handled by ComponentSkin. So a Tooltip constructor that takes a String argument would not help in this case. However, updating ComponentSkin to use a TextArea instead of a Label might be OK. That would allow a caller to embed CRs in the text to facilitate wrapping.

          Show
          Greg Brown added a comment - When using setTooltipText(), a caller does not need to create the tooltip directly - it is handled by ComponentSkin. So a Tooltip constructor that takes a String argument would not help in this case. However, updating ComponentSkin to use a TextArea instead of a Label might be OK. That would allow a caller to embed CRs in the text to facilitate wrapping.
          Hide
          Greg Brown added a comment -

          Renaming issue to more accurately reflect intent and possible solution.

          Show
          Greg Brown added a comment - Renaming issue to more accurately reflect intent and possible solution.
          Hide
          André Thieme added a comment -

          Yes, setTooltipText() takes a String.
          And thanks for explaining the difference of setTootipText and Tooltips, now I understand why you closed this issue.
          setTooltipText already provides what I suggested in the Issue. I agree, one can simply use that method vs.
          creating a fresh Tooltip instance. So yes, replacing the ComponentSkin to use a TextArea would allow singleline
          and multiline Tooltips and thus cover nearly 100% of all use cases.
          Thanks for correcting the topic of the issue. Please reopen it if you think this the default behaviour should be updated.

          Show
          André Thieme added a comment - Yes, setTooltipText() takes a String. And thanks for explaining the difference of setTootipText and Tooltips, now I understand why you closed this issue. setTooltipText already provides what I suggested in the Issue. I agree, one can simply use that method vs. creating a fresh Tooltip instance. So yes, replacing the ComponentSkin to use a TextArea would allow singleline and multiline Tooltips and thus cover nearly 100% of all use cases. Thanks for correcting the topic of the issue. Please reopen it if you think this the default behaviour should be updated.
          Hide
          Greg Brown added a comment -

          I have re-opened the issue. I think it makes sense to consider supporting line breaks by default in tooltips.

          Show
          Greg Brown added a comment - I have re-opened the issue. I think it makes sense to consider supporting line breaks by default in tooltips.
          Hide
          Greg Brown added a comment -

          I prototyped this change, and, in my opinion, it didn't look quite right. The text was left-aligned and seemed like it should be centered. Since TextArea doesn't support an alignment style, it wouldn't be possible to use it here.

          I think a better solution for the long run might be to make it easier for the caller to display a custom tooltip. For example, we could fire an event to signal that a tooltip should be displayed. Not sure exactly what form it should take, but I think this would ultimately be more useful.

          Show
          Greg Brown added a comment - I prototyped this change, and, in my opinion, it didn't look quite right. The text was left-aligned and seemed like it should be centered. Since TextArea doesn't support an alignment style, it wouldn't be possible to use it here. I think a better solution for the long run might be to make it easier for the caller to display a custom tooltip. For example, we could fire an event to signal that a tooltip should be displayed. Not sure exactly what form it should take, but I think this would ultimately be more useful.
          Hide
          Chris Bartlett added a comment -

          What about something along the lines of renderers? Renderer is not quite the right name, and neither are Producer / Provider / Supplier. TooltipContentBuilder?
          I'll continue with the renderer name for the example below.

          Create a TooltipRenderer interface which would be used by the ComponentSkin class.

          Something along the lines of
          public interface TooltipRenderer

          { public Component render(Object component, String tooltipText, Object tooltipData); }

          Add a tooltipRenderer property to Component

          Add a tooltipData property to Component to give as much freedom as possible to developers (or just replace tooltipText)

          It would be the responsibility of this renderer to supply a Component that will be placed into the tooltip popup window.

          A default implementation might just create a Label and set its text to tooltipText.
          A custom implementation would be free to generate whatever graph of components it wanted. It could gather data from the Component parenting the tooltip and/or from the tooltipData object.

          This could be the basis of PIVOT-512

          This could also be taken further to combine tooltip show & hide delays, specifying transitions, rate & delays to create a TooltipPolicy.

          Show
          Chris Bartlett added a comment - What about something along the lines of renderers? Renderer is not quite the right name, and neither are Producer / Provider / Supplier. TooltipContentBuilder? I'll continue with the renderer name for the example below. Create a TooltipRenderer interface which would be used by the ComponentSkin class. Something along the lines of public interface TooltipRenderer { public Component render(Object component, String tooltipText, Object tooltipData); } Add a tooltipRenderer property to Component Add a tooltipData property to Component to give as much freedom as possible to developers (or just replace tooltipText) It would be the responsibility of this renderer to supply a Component that will be placed into the tooltip popup window. A default implementation might just create a Label and set its text to tooltipText. A custom implementation would be free to generate whatever graph of components it wanted. It could gather data from the Component parenting the tooltip and/or from the tooltipData object. This could be the basis of PIVOT-512 This could also be taken further to combine tooltip show & hide delays, specifying transitions, rate & delays to create a TooltipPolicy.
          Hide
          Greg Brown added a comment -

          I understand what you are saying, but I think an event would be simpler. ComponentSkin would simply be updated to respond to the "tooltipTriggered" event rather than "hand rolling" tooltip support using its own internal timer.

          Application specific tooltips could be easily implemented the same way. The listener would just need to create and show the Tooltip instance. The Tooltip class already takes care of the rest (automatically hiding itself when the user moves the mouse).

          Show
          Greg Brown added a comment - I understand what you are saying, but I think an event would be simpler. ComponentSkin would simply be updated to respond to the "tooltipTriggered" event rather than "hand rolling" tooltip support using its own internal timer. Application specific tooltips could be easily implemented the same way. The listener would just need to create and show the Tooltip instance. The Tooltip class already takes care of the rest (automatically hiding itself when the user moves the mouse).
          Hide
          Greg Brown added a comment -

          Component now fires a tooltipTriggered() event that application developers can use to invoke custom tooltips. See the following for an example:

          http://svn.apache.org/repos/asf/pivot/trunk/examples/src/org/apache/pivot/examples/tooltips/

          Show
          Greg Brown added a comment - Component now fires a tooltipTriggered() event that application developers can use to invoke custom tooltips. See the following for an example: http://svn.apache.org/repos/asf/pivot/trunk/examples/src/org/apache/pivot/examples/tooltips/
          Hide
          Chris Bartlett added a comment -

          Unless an alternative solution could make it into the next release, I would vote +1 for making the requested change and use a TextArea instead of a Label.

          I can't see it being a disruptive change (or am I mistaken?), and it allows for simple creation of multi line tooltips.

          I would generally have multiline tooltips left aligned anyway, but don't think that not being able to centre the text should be a show stopper.

          Show
          Chris Bartlett added a comment - Unless an alternative solution could make it into the next release, I would vote +1 for making the requested change and use a TextArea instead of a Label. I can't see it being a disruptive change (or am I mistaken?), and it allows for simple creation of multi line tooltips. I would generally have multiline tooltips left aligned anyway, but don't think that not being able to centre the text should be a show stopper.
          Hide
          Chris Bartlett added a comment -

          Ignore my last comment, I see that you have already addressed it!

          Show
          Chris Bartlett added a comment - Ignore my last comment, I see that you have already addressed it!

            People

            • Assignee:
              Greg Brown
              Reporter:
              André Thieme
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development