swingx
  1. swingx
  2. SWINGX-1387

RolloverProducer: must not fire clicked on release-after-drag

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6.3
    • Fix Version/s: 1.6.3
    • Component/s: Highlighter
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,387

      Description

      title says it all. Turned up while fixing Issue 456 - so marking this as depends on just
      to keep the relation.

      RolloverVisualCheck has a visual test case to expose

        Issue Links

          Activity

          Hide
          kleopatra added a comment -

          After thinking a bit longer ... I think the old behaviour was crooked to start with and completely broke the "click" semantics after the fix the blocking issue

          The whole idea of the click was to support a click-in-cell-coordinates, that is simulate the feel of a button. That makes sense only if the release happens in the same cell as the release (the implementation most probably relies on that fact somewhere anyway, didn't check though). Whoever used it for something else, mis-used it. So we are safe to fix, hehe

          So changed the behaviour to fire a clicked on release if the release happens in same cell. It's decided in an overridable method to allow subclasses to change. If we get a loud uproar, we can add a system/app property to allow unconditional click-on-release. (which was the old incorrect behaviour) More elaborate logic could be added if requested - that would be handled in a new feature issue.

          wiki is unavailabe, forum is more-or-less unwritable ... sigh

          Cheers
          Jeanette

          Show
          kleopatra added a comment - After thinking a bit longer ... I think the old behaviour was crooked to start with and completely broke the "click" semantics after the fix the blocking issue The whole idea of the click was to support a click-in-cell-coordinates, that is simulate the feel of a button. That makes sense only if the release happens in the same cell as the release (the implementation most probably relies on that fact somewhere anyway, didn't check though). Whoever used it for something else, mis-used it. So we are safe to fix, hehe So changed the behaviour to fire a clicked on release if the release happens in same cell. It's decided in an overridable method to allow subclasses to change. If we get a loud uproar, we can add a system/app property to allow unconditional click-on-release. (which was the old incorrect behaviour) More elaborate logic could be added if requested - that would be handled in a new feature issue. wiki is unavailabe, forum is more-or-less unwritable ... sigh Cheers Jeanette
          Hide
          Karl Schaefer added a comment -

          We can do the following. Support both the correct and incorrect behavior for
          the next release and warn users of the change. In the following release,
          remove the bad "click" behavior completely. Gets us going in the right
          direction and gives the users a path for transition.

          Of course, we need to make an announcement of the change on the forums and in
          the wiki.

          Show
          Karl Schaefer added a comment - We can do the following. Support both the correct and incorrect behavior for the next release and warn users of the change. In the following release, remove the bad "click" behavior completely. Gets us going in the right direction and gives the users a path for transition. Of course, we need to make an announcement of the change on the forums and in the wiki.
          Hide
          kleopatra added a comment -

          hmm ... somewhat confused musings ... is it a problem of the producer or of the controller?

          • it's definitely wrong to trigger any action on release-after-drag, after all, it's a
            "clicked" (in terms of mouseEvent equivalents)
          • if some client controller out there depends on getting the clicked (as a stand-in for
            "released") that code will stop to work if we change the producer behaviour

          Jeanette

          Show
          kleopatra added a comment - hmm ... somewhat confused musings ... is it a problem of the producer or of the controller? it's definitely wrong to trigger any action on release-after-drag, after all, it's a "clicked" (in terms of mouseEvent equivalents) if some client controller out there depends on getting the clicked (as a stand-in for "released") that code will stop to work if we change the producer behaviour Jeanette

            People

            • Assignee:
              kleopatra
              Reporter:
              kleopatra
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: