QLineEdit

[GreatSnake]

Я тоже за eventFilter)
Это более гибкое решение в данном случае)

Вот именно, что для данного случая. Но с точки зрения проектирования это костыль.

[Dr.Vlad]

А что делать, если форма уже нарисована (или рисовать ее хочется) в QtDesigner? 
Свои компоненты туда вставлять.
Кстати, почему это хак? На мой взгляд, хак - использование недокументированных методов. Тут же все легально!

Запросто можно вставить писаный класс вместо оригинального QLineEdit в ui_class.h
(только, естессна, перед сборкой под релиз, поскольку первая же очистка обнулит сие деяние)
или же в конструкторе блок QGridLayout ваять.

[kambala]

Запросто можно вставить писаный класс вместо оригинального QLineEdit в ui_class.h

запросто можно преобразовать QLineEdit в писаный класс в дизайнере

[Странник]

запросто можно преобразовать QLineEdit в писаный класс в дизайнере

плюсадин. лучше унаследоваться и сигнал прикрутить, чем при каждой необходимости городить eventFilter'ы.

[Dr.Vlad]

class LineEdit : public QLineEdit
{
        Q_OBJECT
public:
        LineEdit( QWidget* parent = 0 ) : QLineEdit( parent ) {}
 
Q_SIGNALS:
        void clicked();
 
protected:
       void mousePressEvent( QMouseEvent* e )
       {
            QLineEdit::mousePressEvent( e );
            emit clicked();
       }
};

Как будто бы здесь eventFilter НЕ используется...

У нас на работе через installEventFilter всё делают,
хотя сама по себе текстовка любопытная, (так или почти так оригинальные troll классы сделаны), запомню.

[Bepec]

Ну как бы этот слот уже определён. А не прогоняет сквозь себя ВСЕ сигналы повторно.

[_OLEGator_]

У нас на работе через installEventFilter всё делают

И это, имхо, не правильно. Этот механизм скорее для тех, кому влом создавать наследника и там обрабатывать все события, а так было бы правильнее.

[andrew.k]

У нас на работе через installEventFilter всё делают

И это, имхо, не правильно. Этот механизм скорее для тех, кому влом создавать наследника и там обрабатывать все события, а так было бы правильнее.

Не влом, а кому это не нужно.
Нормальный стандартный механизм.

[Bepec]

installEventFilter грузит форму и сигналы. Так же при большом количестве обрабатываемых сигналов (свич из 8 спец элементов допустим), становится сборищем пересекающихся условий и непоняток.
Конечно, если все программисты аккуратны, пишут комментарии и не втыкают через пару дней туда новую функцию, всё будет нормально. Но где ж вы таких видели?

[_OLEGator_]

Не влом, а кому это не нужно.
Нормальный стандартный механизм.

Не нужно = влом. Быстро что-то написать, чтобы работало, наплевав на повторное использование кода. При нормальном проектировании и разработке - надо отдельный класс писать и логику встраивать в него, а не мешать все в кучу. Такой коробочный элемент может быть легко повторно использован.
Конечно, наверняка есть ситуации, когда использование installEventFilter оправдано, но в данном случае это как раз противопоказано.

[andrew.k]

Не влом, а кому это не нужно.
Нормальный стандартный механизм.

Конечно, наверняка есть ситуации, когда использование installEventFilter оправдано, но в данном случае это как раз противопоказано.

Вот именно. Это полноценный метод со своими плюсами и минусами.
Просто начало формироваться мнение, что это какой-то ущербный подход. Словно это GOTO, который есть, но лучше не ипользовать.
Это не так.