Ticket #3597 (closed enhancement: wontfix)

Opened 4 years ago

Last modified 4 years ago

WInput widget: notify owner about changes

Reported by: andrew_b Owned by: andrew_b
Priority: major Milestone:
Component: mc-core Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description (last modified by andrew_b) (diff)

WInput widget should notify it's owner about changes. At least, WInput's owner should know when WInput becomes empty or not empty.

Change History

comment:1 Changed 4 years ago by andrew_b

  • Blocking 3593 added

(In #3593) State changed to "on hold" until #3597 will be implemented.

comment:2 Changed 4 years ago by andrew_b

  • Description modified (diff)

comment:3 Changed 4 years ago by andrew_b

  • Status changed from new to accepted
  • Branch state changed from no branch to on review

Branch: 3597_winput_notify
changeset:d945ccdd1f53f07fcd645e83459f851b060a4971

This changeset can de tested in 3593_find_file_empty_name.

comment:4 follow-up: ↓ 6 Changed 4 years ago by mooffie

This patch makes the notification fire even on keys that don't modify the contents (e.g., on movement keys). This is insignificant for the current need (turning on/off dependent checkboxes) but for tasks that aren't executed "instantly" this might be a concern.

(The reason I care about this isn't nitpicking. In mc2 I use this UI pattern (of triggering some action when WInput changes) in the following modules: visual rename, recently visited files, calculator, find as you type, filter as you type. It happens that computers are fast and users won't notice anything amiss if movement keys trigger spurious actions but this would bother me, as a programmer, still.)

I don't think it's too hard to fix this: input_execute_cmd() has 3 switch statements. We can split the middle one into two: commands that modify the buffer and those that don't. For those that do, we set a 'modified' flag. We shouldn't mind having false positives (the documentation for 'modified' should say so). (The alternative is to keep a copy of the original buffer and compare the contents.)

Otherwise why bother? Instead of implementing a half-cooked notification, the dialog can respond to MSG_POST_KEY; something along of:

cb_ret_t my_dialog_callback(w, ...)
{
    ...
    case MSG_POST_KEY:
        if (DIALOG (w)->current->data == the_input_box)
            /* the text has possibly changed. */
            do_something();  
    ...
}

comment:5 Changed 4 years ago by mooffie

(BTW, I haven't forgotten my responsibility for #3566. I'm working on it.)

comment:6 in reply to: ↑ 4 ; follow-up: ↓ 7 Changed 4 years ago by andrew_b

Replying to mooffie:

Instead of implementing a half-cooked notification, the dialog can respond to MSG_POST_KEY

Indeed. I like this idea. Thanks! I'll implement this for #3593, #3594.

I'd like to close this ticket as wontfix in favour of #3566.

comment:7 in reply to: ↑ 6 Changed 4 years ago by mooffie

Replying to andrew_b:

Replying to mooffie:

Instead of implementing a half-cooked notification, the dialog can respond to MSG_POST_KEY

Indeed. I like this idea. Thanks! I'll implement this for #3593, #3594.

I'd like to close this ticket as wontfix in favour of #3566.


Sure, close it.

comment:8 Changed 4 years ago by andrew_b

  • Status changed from accepted to testing
  • Resolution set to wontfix
  • Blocking 3593, 3594 removed
  • Branch state changed from on review to no branch
  • Milestone 4.8.16 deleted

comment:9 Changed 4 years ago by andrew_b

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.