mirror of
https://github.com/textmate/textmate.git
synced 2026-04-28 03:00:34 -04:00
1002c868c3
This makes the tags accessible (Voice Over) and it simplifies the code as we no longer need to deal with mouse up/down in the chooser itself. I used the rollover image for the pressed state to avoid the button’s default effect, as that looked off when used in a menu. For reference, Finder shows no visual feedback when clicking tags, so we are consistent with Finder. The Finder tag chooser does not forward the enabled state to its subviews, so effectively this commit breaks the enabled property: Do we need to support rendering the view as disabled? I would opt for simply removing support for this property. Unfortunately our custom drawRect: and mouse movement code has not been removed because we need to draw a label based on which tag the mouse is over. I am thinking that the OakRolloverButton could be made to post a notification when mouse enters/leaves, so our Finder tag chooser can observe this notifications and update the label accordingly, which would get rid of all the tracking info. Additionally we should use an NSTextField for the label which would get rid of our custom draw rect and the need to explicitly mark the view as needing display. Lastly the buttons are created in viewDidMoveToSuperview with semi-hardcoded frame rectangles. Although the control has a fixed size, we should probably create the buttons in another method and implement a method to layout the subviews. Constraint-based layout would probably be too complex (to setup the constraints), I believe that in recent versions of macOS, we can simply overload the layout method and place our subviews, but this may not be fully backwards compatible. A minor regression is that mouse clicks that are not on a Finder tag no longer closes the menu. Apple did however change the system behavior some OS versions ago: Previously clicking separators or disabled menu items would close a menu, but now these mouse clicks are ignored. So while I prefer the previous OS behavior, we are consistent with the new behavior (although I think the change was a side-effect of rewriting the menu implementation using NSViews rather then a deliberate design decision)