Ticket #3774 (closed defect: fixed)

Opened 6 weeks ago

Last modified 5 weeks ago

mcedit: Weird coordinates for maximize/close mouse buttons

Reported by: egmont Owned by: zaytsev
Priority: trivial Milestone: 4.8.19
Component: mcedit Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

In the upper row of mcedit, there are two buttons (the actual symbols vary across skins):

[*][X]

Click with the mouse to observe the following:

  • the leftmost [ invokes the pulldown menu (just as if you clicked anywhere to the left),
  • the next three cells: *][ invoke the "(un)maximize" action,
  • the last two cells: X] close the editor.

This looks like a simple off-by-one.

Also, once you unmaximize, the behavior changes there: It's only the exact * and X symbols that perform the given action, the surrounding brackets drag the frame for moving. It would be nice if the maximized and unmaximized cases were consistent. (I guess having all three adjacent cells perform the desired action results in better usability – what do you think?)

Attachments

mc-3774-editor-buttons.patch (1.7 KB) - added by egmont 6 weeks ago.
Fix

Change History

Changed 6 weeks ago by egmont

Fix

comment:1 Changed 5 weeks ago by zaytsev

  • Status changed from new to accepted
  • Owner set to zaytsev
  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8.19

branch: 3774_editor_buttons
changeset: fa951f8c5d8786554abc8bb1a7e1a88f0f03e01a

comment:2 Changed 5 weeks ago by mooffie

  • Votes for changeset set to mooffie

I tested/reviewed the patch and it's fine.

(It's a pity there's now more verbiage that repeats. Perhaps it can be fixed with macros (FUZZY_EQ(event->x, close_x, 1)) or variables (on_close_btn), but maybe we should just leave it as is.)

(And, only in case anybody gets to edit the code again: better fix "int dx"'s comment to read: "/* buttons' distance from right edge */".)

comment:3 Changed 5 weeks ago by egmont

The problem with the FUZZY_EQ approach would be that it only works as long as the overall sensitive width is odd.

I was wondering for a second that maybe I should declare and initialize close_x_start, close_x_end and similarly for the other one, but it wouldn't have significantly simplified things (plus would have introduced the standard doubt: should the end be inclusive or exclusive?).

comment:4 Changed 5 weeks ago by zaytsev

  • Status changed from accepted to testing
  • Votes for changeset changed from mooffie to committed-master
  • Resolution set to fixed
  • Branch state changed from on review to merged

comment:5 Changed 5 weeks ago by zaytsev

  • Status changed from testing to closed

comment:6 Changed 5 weeks ago by zaytsev

Thank you Egmont & Mooffie!

Note: See TracTickets for help on using tickets.