Prefer QLineEdit/QComboBox over KLineEdit/KComboBox where KCompletion features are not needed
Open, Needs TriagePublic

Description

The current wide-spread use of the K variants due to historic reasons going back to the 3 and 4 eras makes it hard to identify where the KCompletion stuff is really needed, and what for.

vkrause created this task.Nov 24 2019, 4:39 PM

Hi,
I use mainly KLineEdit as it has:
" /**

  • By default, KLineEdit recognizes @c Key_Return and @c Key_Enter and emits
  • the returnPressed() signals, but it also lets the event pass,
  • for example causing a dialog's default-button to be called. *
  • Call this method with @p trap = @c true to make @c KLineEdit stop these
  • events. The signals will still be emitted of course. *
  • @see trapReturnKey() */ void setTrapReturnKey(bool trap);

    /**
  • @returns @c true if keyevents of @c Key_Return or
  • @c Key_Enter will be stopped or if they will be propagated. *
  • @see setTrapReturnKey () */ bool trapReturnKey() const;

"
so it avoids to close dialogbox when we press enter in lineedit.
We don't have it in qlineedit for the moment.
or we need to avec a extract method which implement it outside qlineedit but no idea for the moment.
Regards

@dfaure do you have an idea about it ?

This could be done externally by an event filter.

The class could be called KLineEditReturnKeyCatcher or something like that.

Ok I will implement it.
Thanks for idea

This is also a good candidate for upstreaming the feature into Qt... as QLineEdit::setTrapReturnKey for instance. Maybe we should try that first...

Ok why not.
setTrapReturnKey is a good name for you ?

Now that I see "The signals will still be emitted of course" I'm no longer sure.
Trapping sounds like the event is completely eaten and the signal isn't emitted.

This also means the backup plan with an event filter would require more porting (the new class could have a returnPressed signal itself, but that means porting the connects from the lineedit to the Catcher instance, annoying).

So really this is *only* about not closing dialogs, but the lineedit doesn't know/care if some parent is a dialog, so having "Dialog" in the name would be weird/wrong.

setPropagateReturnKey(false) might be a better name? (technically setPropagateReturnKeyEvents but that's a bit long...)

Ok I will create a patch soon against qt5.15.

Thanks