Pivot
  1. Pivot
  2. PIVOT-458

Add a "repeatable" property to ListButton

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: wtk
    • Labels:
      None

      Description

      I found this to be a requirement in my application: if the user clicks the label part of a LinkButton, the button should fire immediately without showing the popup, thus invoking the action with the currently selected entry. If the user clicks the triangle part, the popup should be shown.

      I patched LinkButton to add a new boolean property called "showPopupOnTriggerClickOnly" to TerraListButtonSkin (I couldn't think of a better name, sorry). If set to true, the ListButton popup will only show up if the user clicks the triangle, but not if the user clicks the rest of the button. However, ButtonPressListeners fire as usual, if the user clicks any part of the button. If the property is false, the behavior is as it was before. The default value of the property is false.

      I tested the patch in my application and ComponentExplorer and it works good.

      It would be nice if you integrate the patch. Otherwise I'd still have the option to write a custom skin, but I think this patch could be interesting to other developers as well.

      1. office-listbutton-triggerclicked.png
        5 kB
        Dirk Moebius
      2. office-listbutton-pressed.png
        0.7 kB
        Dirk Moebius
      3. office-listbutton-normal.png
        0.6 kB
        Dirk Moebius
      4. office-listbutton-hovered.png
        0.7 kB
        Dirk Moebius
      5. listbutton-popup-splitpaint.patch
        8 kB
        Dirk Moebius
      6. ASF.LICENSE.NOT.GRANTED--menubutton-popup.patch
        2 kB
        Dirk Moebius
      7. ASF.LICENSE.NOT.GRANTED--listbutton-popup.patch
        3 kB
        Dirk Moebius

        Activity

        Hide
        Greg Brown added a comment -

        We had actually planned to implement this behavior for MenuButton, but I hadn't considered it for ListButton. I'm not entirely opposed to supporting it in ListButton as well, but I'm wondering if your use case might be better suited to a menu button (in general, menu buttons are meant to trigger actions, whereas list buttons do not).

        Show
        Greg Brown added a comment - We had actually planned to implement this behavior for MenuButton, but I hadn't considered it for ListButton. I'm not entirely opposed to supporting it in ListButton as well, but I'm wondering if your use case might be better suited to a menu button (in general, menu buttons are meant to trigger actions, whereas list buttons do not).
        Hide
        Dirk Moebius added a comment -

        If you want I'll give you a patch with the same changes to TerraMenuButtonSkin.

        Show
        Dirk Moebius added a comment - If you want I'll give you a patch with the same changes to TerraMenuButtonSkin.
        Hide
        Dirk Moebius added a comment -

        > (in general, menu buttons are meant to trigger actions, whereas list buttons do not)

        Uh, list buttons do trigger actions. ?!?

        MenuButton is not exactly the same: with ListButton I can sort of "select an action", and then repeatedly invoke the same action by hitting the button again and again. With MenuButton, the label and icon don't change if I select an entry. (Of course I could do that programmatically).

        Show
        Dirk Moebius added a comment - > (in general, menu buttons are meant to trigger actions, whereas list buttons do not) Uh, list buttons do trigger actions. ?!? MenuButton is not exactly the same: with ListButton I can sort of "select an action", and then repeatedly invoke the same action by hitting the button again and again. With MenuButton, the label and icon don't change if I select an entry. (Of course I could do that programmatically).
        Hide
        Greg Brown added a comment -

        By all means, please feel free to submit a patch for MenuButton as well. The feature is captured here:

        https://issues.apache.org/jira/browse/PIVOT-24

        Maybe we could also use the term "split" in TerraListButtonSkin (vs. the accurate but slightly more verbose "showPopupOnTriggerClickOnly"). I'm not married to "split", though - other suggestions are welcome.

        Show
        Greg Brown added a comment - By all means, please feel free to submit a patch for MenuButton as well. The feature is captured here: https://issues.apache.org/jira/browse/PIVOT-24 Maybe we could also use the term "split" in TerraListButtonSkin (vs. the accurate but slightly more verbose "showPopupOnTriggerClickOnly"). I'm not married to "split", though - other suggestions are welcome.
        Hide
        Greg Brown added a comment -

        Yeah. This is a really old ticket (obviously, since it is #24), and it actually dates back even further. I'm thinking that maybe it would be best to add this feature to ListButton and forget about it for MenuButton.

        What do you think of "split" as a style name?

        Show
        Greg Brown added a comment - Yeah. This is a really old ticket (obviously, since it is #24), and it actually dates back even further. I'm thinking that maybe it would be best to add this feature to ListButton and forget about it for MenuButton. What do you think of "split" as a style name?
        Hide
        Dirk Moebius added a comment - - edited

        Here's the patch for MenuButton.

        On second thought, I might need this behavior on both MenuButton and LinkButton in my application.

        I'm opposed to "split" - this name doesn't seam to explain anything to me.

        How about a reversed boolean "popupOnBodyClick": default true ?!? (Or: "popupOnLabel" ?)

        Show
        Dirk Moebius added a comment - - edited Here's the patch for MenuButton. On second thought, I might need this behavior on both MenuButton and LinkButton in my application. I'm opposed to "split" - this name doesn't seam to explain anything to me. How about a reversed boolean "popupOnBodyClick": default true ?!? (Or: "popupOnLabel" ?)
        Hide
        Greg Brown added a comment -

        "Split" means that the button is split in two. "Divided" is another similar option.

        Show
        Greg Brown added a comment - "Split" means that the button is split in two. "Divided" is another similar option.
        Hide
        Greg Brown added a comment -

        I think "SplitButton" is a pretty common term for this type of widget. For example:

        http://www.codeproject.com/KB/WPF/WpfSplitButton.aspx

        So my vote would be for "split".

        Show
        Greg Brown added a comment - I think "SplitButton" is a pretty common term for this type of widget. For example: http://www.codeproject.com/KB/WPF/WpfSplitButton.aspx So my vote would be for "split".
        Hide
        Greg Brown added a comment -

        Spoke offline with Todd about this - he is also open to other suggestions, but concurs that "split" is an appropriate term for this behavior.

        Show
        Greg Brown added a comment - Spoke offline with Todd about this - he is also open to other suggestions, but concurs that "split" is an appropriate term for this behavior.
        Hide
        Greg Brown added a comment -

        FYI, I applied the patch and it looks good overall. However, I now think I see why "split" may not have made sense to you. When this style is set to true, I would expect that clicking on the trigger would only show the trigger pressed state, and vice versa for the content area (the non-trigger section) of the button. However, as currently implemented, the entire button appears pressed regardless of which side is clicked.

        Would you be willing to take a stab at implementing this behavior? I think it will involve maintaining a value representing which part of the button is pressed and painting the proper pressed state in paint(). A simple boolean "triggerPressed" flag may suffice, since TerraListButtonSkin already inherits a "pressed" member from the base class.

        Show
        Greg Brown added a comment - FYI, I applied the patch and it looks good overall. However, I now think I see why "split" may not have made sense to you. When this style is set to true, I would expect that clicking on the trigger would only show the trigger pressed state, and vice versa for the content area (the non-trigger section) of the button. However, as currently implemented, the entire button appears pressed regardless of which side is clicked. Would you be willing to take a stab at implementing this behavior? I think it will involve maintaining a value representing which part of the button is pressed and painting the proper pressed state in paint(). A simple boolean "triggerPressed" flag may suffice, since TerraListButtonSkin already inherits a "pressed" member from the base class.
        Hide
        Dirk Moebius added a comment -

        Ok, I'll do it tomorrow - but I think this opens a whole new can of worms: what to do with focus traversal? If "split" is "on", should the focus actually travel through two buttons, so that each of them can be pressed by typing SPACE?

        Show
        Dirk Moebius added a comment - Ok, I'll do it tomorrow - but I think this opens a whole new can of worms: what to do with focus traversal? If "split" is "on", should the focus actually travel through two buttons, so that each of them can be pressed by typing SPACE?
        Hide
        Greg Brown added a comment -

        That is a great point - I hadn't thought about focus traversal in this case. I don't think we'd want to split the focus - no other component works that way, and I'm not even sure how we would represent it (the focus rect is currently drawn around the content).

        I'll give it some more thought, but I think that it would probably make sense to have the space bar register as a press on the content part of the button when "split" is true. The user can still navigate through the items using the arrow keys, and we could provide an auxiliary keystroke combination to show the popup (e.g. shift-space, or shift-down arrow). We could enable that combination even when the button is not split.

        The more I think about it, the more I am on the fence about adding this behavior to MenuButton as well. MenuButton doesn't currently draw a divider between the content and the trigger - if we were to add one, the user wouldn't be able to distinguish a menu button from a list button.

        Show
        Greg Brown added a comment - That is a great point - I hadn't thought about focus traversal in this case. I don't think we'd want to split the focus - no other component works that way, and I'm not even sure how we would represent it (the focus rect is currently drawn around the content). I'll give it some more thought, but I think that it would probably make sense to have the space bar register as a press on the content part of the button when "split" is true. The user can still navigate through the items using the arrow keys, and we could provide an auxiliary keystroke combination to show the popup (e.g. shift-space, or shift-down arrow). We could enable that combination even when the button is not split. The more I think about it, the more I am on the fence about adding this behavior to MenuButton as well. MenuButton doesn't currently draw a divider between the content and the trigger - if we were to add one, the user wouldn't be able to distinguish a menu button from a list button.
        Hide
        Dirk Moebius added a comment -

        There's a component similar to ListButton: a Spinner, having two triggers up/down instead of one. Space triggers the button press action, cursor up/down selects through the items, and there's no way to focus the trigger buttons (it is not needed).

        How about this:

        1. ListButton:
        a) space: in split mode it's like button press, in normal mode it shows the popup (just like a mouse click)
        b) cursor up/down: cycles through items
        c) shift-space or shift-down: shows popup in any mode (TBD later)
        2. MenuButton:
        a) space: in split mode it's like button press, in normal mode it shows the popup (just like a mouse click)
        b) cursor down: shows menu

        Show
        Dirk Moebius added a comment - There's a component similar to ListButton: a Spinner, having two triggers up/down instead of one. Space triggers the button press action, cursor up/down selects through the items, and there's no way to focus the trigger buttons (it is not needed). How about this: 1. ListButton: a) space: in split mode it's like button press, in normal mode it shows the popup (just like a mouse click) b) cursor up/down: cycles through items c) shift-space or shift-down: shows popup in any mode (TBD later) 2. MenuButton: a) space: in split mode it's like button press, in normal mode it shows the popup (just like a mouse click) b) cursor down: shows menu
        Hide
        Greg Brown added a comment -

        Help me understand the use case for split behavior in a MenuButton. Unlike ListButtons, MenuButtons don't maintain any kind of selection state - so what would clicking on the just content area mean? To a large extent, MenuButtons exist to provide access to a menu popup. The button itself doesn't really offer much on its own.

        I know that I originally suggested that this behavior belongs in MenuButton and not ListButton, but the to-do in PIVOT-24 actually goes back a really long way, back to when Pivot wasn't even called Pivot and was actually implemented in JavaScript, not Java. Back then, menu buttons were backed by list data, much like list buttons, and might have one day been given support for some kind of selection state. However, in their current incarnation, they are not data driven, and are more like menu items that can exist outside of a menu or menu bar. And there is still the issue of UI design. Menu buttons visually distinguish themselves from list buttons by not drawing a divider. I'd like to maintain that distinction.

        I'm now 100% in favor of adding this behavior to ListButton - perhaps that would be sufficient for your needs now, and we could revisit MenuButton in a future release, if appropriate?

        Show
        Greg Brown added a comment - Help me understand the use case for split behavior in a MenuButton. Unlike ListButtons, MenuButtons don't maintain any kind of selection state - so what would clicking on the just content area mean? To a large extent, MenuButtons exist to provide access to a menu popup. The button itself doesn't really offer much on its own. I know that I originally suggested that this behavior belongs in MenuButton and not ListButton, but the to-do in PIVOT-24 actually goes back a really long way, back to when Pivot wasn't even called Pivot and was actually implemented in JavaScript, not Java. Back then, menu buttons were backed by list data, much like list buttons, and might have one day been given support for some kind of selection state. However, in their current incarnation, they are not data driven, and are more like menu items that can exist outside of a menu or menu bar. And there is still the issue of UI design. Menu buttons visually distinguish themselves from list buttons by not drawing a divider. I'd like to maintain that distinction. I'm now 100% in favor of adding this behavior to ListButton - perhaps that would be sufficient for your needs now, and we could revisit MenuButton in a future release, if appropriate?
        Hide
        Dirk Moebius added a comment -

        Excuse me, Greg, I'm not very good in explaining this.

        I see it this way:

        A MenuButton is first and foremost a button, that has a menu attached. Like all buttons, pressing the button invokes the action. Furthermore, it has a menu attached. You can invoke the menu by clicking the triangle, or optionally have it shown every time you click the button.

        If the MenuButton would not fire an action when it is clicked it wouldn't be a menu button. It would be a menu only.

        Those two facts apply to ListButton as well. The difference is: A ListButton has a selection state, while the MenuButton has not. (More exactly: the submenu of the MenuButton has a selection state, but the MenuButton itself has not!). Clicking the button of a ListButton invokes the action that is attached to the current selection state. Clicking the button of a MenuButton simply invokes its action, no matter what. So with ListButton, a user can customize which action should be invoked if single-clicked, whereas with MenuButton you cannot customize the "main action" that is to be invoked if single-clicked. The "main action" in a MenuButton is always the action that is described by the button's label. The "main action" in a ListButton is the action, that the user selected.

        Usecase:

        Suppose you have a TableView with some data with multi-select on. Above the table is a toolbar of buttons, which are supposed to perform some operations on the selected rows. There's a MenuButton displaying "Add selected". If you click the MenuButton, the selected table rows are added to some other model entity. But the MenuButton's menu also has menu items for "Add at top", "Add at bottom", "Replace existing entries". The user can invoke one of these 4 actions. The "Add selected" action is the default action. But this action won't be replaced if the user chooses another entry of MenuButton's menu. Had I used a ListButton, the latest selected action would replace the default action "Add selected", but that is not intended.

        Show
        Dirk Moebius added a comment - Excuse me, Greg, I'm not very good in explaining this. I see it this way: A MenuButton is first and foremost a button, that has a menu attached. Like all buttons, pressing the button invokes the action. Furthermore, it has a menu attached. You can invoke the menu by clicking the triangle, or optionally have it shown every time you click the button. If the MenuButton would not fire an action when it is clicked it wouldn't be a menu button . It would be a menu only. Those two facts apply to ListButton as well. The difference is: A ListButton has a selection state, while the MenuButton has not. (More exactly: the submenu of the MenuButton has a selection state, but the MenuButton itself has not!). Clicking the button of a ListButton invokes the action that is attached to the current selection state. Clicking the button of a MenuButton simply invokes its action, no matter what. So with ListButton, a user can customize which action should be invoked if single-clicked, whereas with MenuButton you cannot customize the "main action" that is to be invoked if single-clicked. The "main action" in a MenuButton is always the action that is described by the button's label. The "main action" in a ListButton is the action, that the user selected. Usecase: Suppose you have a TableView with some data with multi-select on. Above the table is a toolbar of buttons, which are supposed to perform some operations on the selected rows. There's a MenuButton displaying "Add selected". If you click the MenuButton, the selected table rows are added to some other model entity. But the MenuButton's menu also has menu items for "Add at top", "Add at bottom", "Replace existing entries". The user can invoke one of these 4 actions. The "Add selected" action is the default action. But this action won't be replaced if the user chooses another entry of MenuButton's menu. Had I used a ListButton, the latest selected action would replace the default action "Add selected", but that is not intended.
        Hide
        Greg Brown added a comment -

        > More exactly: the submenu of the MenuButton has a selection state, but the MenuButton itself has not!

        This is exactly my point - the submenu doesn't actually have a selection state. Menu items (instances of Menu.Item) are also buttons. A Menu instance doesn't "remember" the last menu item you selected - it just provides a popup window via which you can select them (a menu is basically just a collection of buttons). This is different from a list button, which shows a ListView when clicked. List views (and list buttons) do maintain selection state (i.e. "remember" what you selected).

        > The "main action" in a MenuButton is always the action that is described by the button's label. The "main action" in a ListButton is the action, that the user selected.

        Buttons serve many purposes in an application, and not all are meant to be associated with an action. For example, clicking on a checkbox or radio button is generally not meant to trigger an action. Actions associated with these components are generally triggered by another mechanism (such as a push button). Checkbox and RadioButton extend Button because they share some common functionality, but their emphasis is not on the action (the action-oriented buttons primarily include PushButton and Menu.Item). ListButton and MenuButton are also not generally associated with Actions - the emphasis of a ListButton is on its selection state, and the emphasis of a MenuButton is on the actions associated with the menu items, not the menu button itself.

        > Suppose you have a TableView with some data with multi-select on...

        I think the use case you describe may be confusing for users, since it is not clear what "add selected" would actually do. Does it "add at top", "add at bottom", or "replace existing entries"?

        To me, "add selected" seems like more of an action heading than an action itself. Clicking the menu button allows the user to select a specific "add" action to perform by selecting one of the menu items.

        OTOH, if you were to use a split ListButton in this case, I think it would make more sense. The list button would always show one of the actual options ("add at top", "add at bottom", or "replace existing entries"). Then it would be clear to the user exactly what will happen when the content part of the button is clicked.

        Hope this makes sense.

        Show
        Greg Brown added a comment - > More exactly: the submenu of the MenuButton has a selection state, but the MenuButton itself has not! This is exactly my point - the submenu doesn't actually have a selection state. Menu items (instances of Menu.Item) are also buttons. A Menu instance doesn't "remember" the last menu item you selected - it just provides a popup window via which you can select them (a menu is basically just a collection of buttons). This is different from a list button, which shows a ListView when clicked. List views (and list buttons) do maintain selection state (i.e. "remember" what you selected). > The "main action" in a MenuButton is always the action that is described by the button's label. The "main action" in a ListButton is the action, that the user selected. Buttons serve many purposes in an application, and not all are meant to be associated with an action. For example, clicking on a checkbox or radio button is generally not meant to trigger an action. Actions associated with these components are generally triggered by another mechanism (such as a push button). Checkbox and RadioButton extend Button because they share some common functionality, but their emphasis is not on the action (the action-oriented buttons primarily include PushButton and Menu.Item). ListButton and MenuButton are also not generally associated with Actions - the emphasis of a ListButton is on its selection state, and the emphasis of a MenuButton is on the actions associated with the menu items, not the menu button itself. > Suppose you have a TableView with some data with multi-select on... I think the use case you describe may be confusing for users, since it is not clear what "add selected" would actually do. Does it "add at top", "add at bottom", or "replace existing entries"? To me, "add selected" seems like more of an action heading than an action itself. Clicking the menu button allows the user to select a specific "add" action to perform by selecting one of the menu items. OTOH, if you were to use a split ListButton in this case, I think it would make more sense. The list button would always show one of the actual options ("add at top", "add at bottom", or "replace existing entries"). Then it would be clear to the user exactly what will happen when the content part of the button is clicked. Hope this makes sense.
        Hide
        Dirk Moebius added a comment -

        > Buttons serve many purposes in an application, and not all are meant to be associated with an action. For example, clicking on a checkbox or radio button is generally not meant to trigger an action.

        Generally yes, but there are exceptions. I find if very convenient that I can attach an action to a checkbox/radio button/list button/menu button, and I'm glad that those components fire action events so that I don't have to attach a mouse listener to them.

        > I think the use case you describe may be confusing for users, since it is not clear what "add selected" would actually do. Does it "add at top", "add at bottom", or "replace existing entries"?

        You're right. My example was contrived, but if I had used only the three actions "add at top", "add at bottom" and "replace" (with "add at top" being the default action) it becomes more clear what I meant.

        > To me, "add selected" seems like more of an action heading than an action itself. Clicking the menu button allows the user to select a specific "add" action to perform by selecting one of the menu items.

        Ok.

        > OTOH, if you were to use a split ListButton in this case, I think it would make more sense. The list button would always show one of the actual options ("add at top", "add at bottom", or "replace existing entries"). Then it would be clear to the user exactly what will happen when the content part of the button is clicked.

        Yes, right. But the action that the user selected remains after being executed. The ListButton doesn't snap back to the default action. Of course I could to that programmatically.

        Ok, all in all you've convinced me. I'd be happy if the patch is applied to ListButton only, and I don't care if the property is called "split" or "showPopupOnTriggerClickOnly" or "makeThePopupShowUpOnlyIfTheLittleTriangleRightOfTheButtonLabelIsClickedButNotIfTheButtonsLabelItselfIsClicked" or whatever.

        Show
        Dirk Moebius added a comment - > Buttons serve many purposes in an application, and not all are meant to be associated with an action. For example, clicking on a checkbox or radio button is generally not meant to trigger an action. Generally yes, but there are exceptions. I find if very convenient that I can attach an action to a checkbox/radio button/list button/menu button, and I'm glad that those components fire action events so that I don't have to attach a mouse listener to them. > I think the use case you describe may be confusing for users, since it is not clear what "add selected" would actually do. Does it "add at top", "add at bottom", or "replace existing entries"? You're right. My example was contrived, but if I had used only the three actions "add at top", "add at bottom" and "replace" (with "add at top" being the default action) it becomes more clear what I meant. > To me, "add selected" seems like more of an action heading than an action itself. Clicking the menu button allows the user to select a specific "add" action to perform by selecting one of the menu items. Ok. > OTOH, if you were to use a split ListButton in this case, I think it would make more sense. The list button would always show one of the actual options ("add at top", "add at bottom", or "replace existing entries"). Then it would be clear to the user exactly what will happen when the content part of the button is clicked. Yes, right. But the action that the user selected remains after being executed. The ListButton doesn't snap back to the default action. Of course I could to that programmatically. Ok, all in all you've convinced me. I'd be happy if the patch is applied to ListButton only, and I don't care if the property is called "split" or "showPopupOnTriggerClickOnly" or "makeThePopupShowUpOnlyIfTheLittleTriangleRightOfTheButtonLabelIsClickedButNotIfTheButtonsLabelItselfIsClicked" or whatever.
        Hide
        Greg Brown added a comment -

        I'd be happy to apply the list button patch when the paint() method has been updated to paint the split state. Are you still planning to do that?

        Show
        Greg Brown added a comment - I'd be happy to apply the list button patch when the paint() method has been updated to paint the split state. Are you still planning to do that?
        Hide
        Greg Brown added a comment -

        FYI, if you are working on this issue, you can assign it to yourself and mark it as in-progress. That way others will be aware that it is already being worked on.

        Show
        Greg Brown added a comment - FYI, if you are working on this issue, you can assign it to yourself and mark it as in-progress. That way others will be aware that it is already being worked on.
        Hide
        Dirk Moebius added a comment -

        Can't. I'm not assigned to the Pivot project, so the JIRA workflow won't let me assign myself.

        Ok, I'm working on it. I'll do the following:
        If split mode is off, pressing any part of the ListButton shows the pressed state on the whole button, as before.
        If split mode is on, pressing the content part of the ListButton shows the pressed state on the content part only, instead of the whole button.
        If split mode is on, pressing the triangle shows the pressed state on the whole button, not the triangle part only, because otherwise it looks strange.

        Show
        Dirk Moebius added a comment - Can't. I'm not assigned to the Pivot project, so the JIRA workflow won't let me assign myself. Ok, I'm working on it. I'll do the following: If split mode is off, pressing any part of the ListButton shows the pressed state on the whole button, as before. If split mode is on, pressing the content part of the ListButton shows the pressed state on the content part only, instead of the whole button. If split mode is on, pressing the triangle shows the pressed state on the whole button , not the triangle part only, because otherwise it looks strange.
        Hide
        Greg Brown added a comment -

        > Can't. I'm not assigned to the Pivot project, so the JIRA workflow won't let me assign myself.

        I just added you as a Contributor, so you should be able to assign the issue to yourself now.

        > If split mode is on, pressing the triangle shows the pressed state on the whole button, not the triangle part only, because otherwise it looks strange.

        Interesting. For reference, I just looked at the ExtJS split button to see how it behaves. It does not paint a different state depending on where the user clicks, so I couldn't get a sense for what this looks like. I also looked for a Silverlight example but I couldn't find one. Any idea how the Windows split button handles this?

        Show
        Greg Brown added a comment - > Can't. I'm not assigned to the Pivot project, so the JIRA workflow won't let me assign myself. I just added you as a Contributor, so you should be able to assign the issue to yourself now. > If split mode is on, pressing the triangle shows the pressed state on the whole button , not the triangle part only, because otherwise it looks strange. Interesting. For reference, I just looked at the ExtJS split button to see how it behaves. It does not paint a different state depending on where the user clicks, so I couldn't get a sense for what this looks like. I also looked for a Silverlight example but I couldn't find one. Any idea how the Windows split button handles this?
        Hide
        Greg Brown added a comment -

        I just committed a modified version of this patch (I renamed the style to "split"). Looking at it again, I think the UE is OK. You are welcome to implement the split paint behavior if you like, or we can revisit it another time. Up to you.

        Show
        Greg Brown added a comment - I just committed a modified version of this patch (I renamed the style to "split"). Looking at it again, I think the UE is OK. You are welcome to implement the split paint behavior if you like, or we can revisit it another time. Up to you.
        Hide
        Dirk Moebius added a comment -

        Here are 3 screenshots of the color split button in Microsoft Word 2003. In normal mode, the button does not render a separator between the button and the trigger (just like Pivots MenuButton). In hovered mode it does. If the content part is pressed, only the content part is painted with a pressed state. The popup does not open. If the trigger part is pressed, the popup opens and the whole component renders all differently.

        Show
        Dirk Moebius added a comment - Here are 3 screenshots of the color split button in Microsoft Word 2003. In normal mode, the button does not render a separator between the button and the trigger (just like Pivots MenuButton). In hovered mode it does. If the content part is pressed, only the content part is painted with a pressed state. The popup does not open. If the trigger part is pressed, the popup opens and the whole component renders all differently.
        Hide
        Greg Brown added a comment -

        Right - the "open" state draws the popup as if it was attached to the button, which is nice. However, that's probably beyond the scope of what we need to do for now. We are generally deferring significant L&F changes to v2.0 or later, when we plan to invest time in doing a full overhaul of the UI.

        If the current version works for you, my vote would be to leave it as-is for now.

        Nice work - thanks for the submission.

        Show
        Greg Brown added a comment - Right - the "open" state draws the popup as if it was attached to the button, which is nice. However, that's probably beyond the scope of what we need to do for now. We are generally deferring significant L&F changes to v2.0 or later, when we plan to invest time in doing a full overhaul of the UI. If the current version works for you, my vote would be to leave it as-is for now. Nice work - thanks for the submission.
        Hide
        Dirk Moebius added a comment -

        > I just added you as a Contributor, so you should be able to assign the issue to yourself now.

        Thanks.

        > I just committed a modified version of this patch (I renamed the style to "split"). Looking at it again, I think the UE is OK. You are welcome to implement the split paint behavior if you like, or we can revisit it another time. Up to you.

        Well, I had already begun with it, but I'm not happy with the patch:

        • pressing SPACE in split mode doesn't show the popup but fires the ButtonPressed event. There's no way to show the popup if split mode is on, because I didn't implement the SHIFT-DOWN function.
        • I had to overwrite too many methods from ListButtonSkin to maintain the 'triggerPressed' boolean state (enableChanged(), focusChanged(), mouseOut(), mouseDown(), keyPressed(), keyReleased())

        FWIW, here's my modification I had done so far, just for reference. Please do not include it.

        Show
        Dirk Moebius added a comment - > I just added you as a Contributor, so you should be able to assign the issue to yourself now. Thanks. > I just committed a modified version of this patch (I renamed the style to "split"). Looking at it again, I think the UE is OK. You are welcome to implement the split paint behavior if you like, or we can revisit it another time. Up to you. Well, I had already begun with it, but I'm not happy with the patch: pressing SPACE in split mode doesn't show the popup but fires the ButtonPressed event. There's no way to show the popup if split mode is on, because I didn't implement the SHIFT-DOWN function. I had to overwrite too many methods from ListButtonSkin to maintain the 'triggerPressed' boolean state (enableChanged(), focusChanged(), mouseOut(), mouseDown(), keyPressed(), keyReleased()) FWIW, here's my modification I had done so far, just for reference. Please do not include it.
        Hide
        Greg Brown added a comment -

        Updated summary.

        Show
        Greg Brown added a comment - Updated summary.
        Hide
        Greg Brown added a comment -

        Note that this change will require some additional changes to how events are handled in these components. Button press isn't currently fired until after the click event, which isn't consistent with most other UI toolkits (which show the popup on mouse down).

        Also, button press invokes the button's action, which we don't necessarily want to do:

        • ListButton, CalendarButton, and ColorPickerButton should only fire button press when split and the content area is clicked, or a list item is selected.
        • MenuButton should never fire button press.

        Finally, we may want to draw a divider between the content area and the trigger when "split" is true, as well as show a hover state like we do in Spinner.

        Show
        Greg Brown added a comment - Note that this change will require some additional changes to how events are handled in these components. Button press isn't currently fired until after the click event, which isn't consistent with most other UI toolkits (which show the popup on mouse down). Also, button press invokes the button's action, which we don't necessarily want to do: ListButton, CalendarButton, and ColorPickerButton should only fire button press when split and the content area is clicked, or a list item is selected. MenuButton should never fire button press. Finally, we may want to draw a divider between the content area and the trigger when "split" is true, as well as show a hover state like we do in Spinner.
        Hide
        Greg Brown added a comment -

        Since this change has deeper ramifications than we initially suspected, I am moving it to 1.5.1.

        Show
        Greg Brown added a comment - Since this change has deeper ramifications than we initially suspected, I am moving it to 1.5.1.
        Hide
        Greg Brown added a comment -

        The skins for ListButton, CalendarButton, ColorChooserButton, and MenuButton have been updated to show the popup on mouse down and key pressed, which is consistent with similar components on Windows and Mac OS X. Split behavior has not yet been added to ListButton.

        Show
        Greg Brown added a comment - The skins for ListButton, CalendarButton, ColorChooserButton, and MenuButton have been updated to show the popup on mouse down and key pressed, which is consistent with similar components on Windows and Mac OS X. Split behavior has not yet been added to ListButton.

          People

          • Assignee:
            Greg Brown
            Reporter:
            Dirk Moebius
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development