Qt5 QMenu QMenubar пропускает один клик

Переопредели mousePressEvent и посмотри, доходят ли клики до меню.

Не теряет ни одного клика, но начиная со второго. Т.е. первый клик хватает не меню, а менюбар или хз кто. Проверяю.

Не окно, значит менюбар. И что мне с ним делать? Это бага или что? Воспроизводится?

Версия Qt какая?

P.S. почему бы не воспользоваться Qt Designer-ом для формошлёпства?

5.3.2

А я шлепал. Только какой смысл шлепать когда не понятно как оно работает? Я не собираюсь сидеть в формошлепщике всю жись.

... и fluorite

Ну ахринеть! Виноват был вложенный:

centralWidget->layout->splitter->widget->layout->splitter->widget->layout->QGLWidget

Отрубил, заменил на QWidget и проблема пропала. С гыэль буду разбираться когда до него доберусь непосредственно.

В 5.3.2 емнип много косячков было, например потеря первого символа при вводе после смены раскладки, или что-то подобное.

Не стоит лезть в дебри с самого начала. И нет ничего плохого в дизайнере. Не думайте, что он чисто для новичков. Почти любой Qt софт его использует. Какой дурак будет вручную это описывать?

Подтверждаю. Уже напоролся в лингвисте, который идет вместе с кумейками.

Ставь последнюю версию Qt 5, она хоть как-то стабилизировалась.

То, что было до Qt 5.5 вообще забагованный ад и Израиль.

Я вручную пишу. Именно чтобы разобраться. Естественно я сначала нашлепал и посмотрел что там генерится, изучил. Руками, кстати, гораздо меньше кода получается, и чистый. А это — глюк вообще другого виджета и не моя ошибка.

Если б ты мне вкратце рассказал как эту новую культю вконпелять прямо в приложение — буду благодарен. Только предупреждаю, я в плюсы впервые и в культи впервые и в кумейк впервые. Так что как для дебильчика, если можно. Где там путь какой указать или вариаблю экспортнуть, какие флаги скормить.

А зачем тебе «прямо в приложение»? Делай как описано в документации:

http://doc.qt.io/qt-5/linux-deployment.html#creating-the-application-package

А новый Qt скачивается с сайта и инсталятором ставится куда-нибудь в /opt

И еще чисто плюсовой вопрос. Кроме как экстерном никак нельзя сделать глобальный (сейчас у меня статика) «синглтон» доступным внутри вложенных вложенных вложенных областей видимости в разных файлах?

Годно. Запробую. Спасибо.

Руками, кстати, гораздо меньше кода получается, и чистый.

Обычно - нет. Формочку с десятком лайоутов и 50-ю виджетами клепать вручную будет ад. Ну и в дизайнере сразу видно результат. Когда начнёте сложные QGridLayout делать - поймёте зачем нужен дизайнер.

Смотря какой синглтон. extern - это ужас.

Классический:

class Singletone
{
public:
    static Singletone& get() {
        static Singletone instance;
        return instance;
    }

private:
    Singletone() {}
    Q_DISABLE_COPY(Singletone)
};

Еще есть монстры типа https://wiki.qt.io/Qt_thread-safe_singleton или Q_GLOBAL_STATIC. На вкус и цвет, как говорится.

Разделяй и властвуй. Работай с уровнем вложения не глубже первого, а во вложении работай с его вложениями. Да, файлов много. Да, виджеты могут быть не в глобальном скопе (у меня так), но, зато в каждом файле мало строк и все по полочкам. Есть минус — я спросил за глобальный синглтон сообщением выше, нужно чтобы сигналы и слоты коннектить меж теми кто друг друга не видит. Если есть архитектурное решение лучше (именно об этом я спрашивал в той другой теме) — я готов выслушать.

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

Треды будут, но постараюсь в минимум мьютексов, где не критично ожидание пока культя разгребет очередь, там будут сигналы.

Q_GLOBAL_STATIC

Годно! Очень нравится что в культях есть все что может понадобиться.

Если я правильно помню, это каноничный синглтон Майерса, и как минимум с С++11 он потокобезопасен.

Годно! Очень нравится что в культях есть все что может понадобиться.

Может не стоит коверкать название библиотеки которая нравится? Вообще, коверкать что угодно, будь то фамилии политиков или названия продуктов — моветон.

но, зато в каждом файле мало строк и все по полочкам.

И сборка в 10 раз медленнее. Для меня нормальный класс - 1к строк.

Вы что-то делаете не так.

Осталось называть либу по-человечески.

Без понятия. Многопоточность в плюсах - ад.

Он собирает только то, что изменялось. Медленно только в первый раз, когда ни объектников ни моков нет.

Вот и спрашиваю а как правильно.

Если речь идет о том, что все виджеты должны быть инициализированы в одном скопе. Это значит, по моему мнению, там будет простыня-помойка (именно такую помойку генерит креатор). Если речь о чем-то другом — объясните.

О какой простыне идёт речь?

Есть декларация, есть реализация, есть использование. С моей точки зрения, подключение всех деклараций и использование всех реализаций в одном месте, в одном скопе — помойка, то, что делает креатор в файле ui_mainwindow.h. Сейчас, кроме как либо устраивать помойку, либо делать глобальный объект состояния/синглтон для возможности общения виджетов между собой — других вариантов не вижу. Помойку делать не хочу, я же пишу сейчас руками и запутаюсь. Выбираю глобальный объект, но вы говорите что это не верно. Какие еще варианты? Ну кроме бросить все нафик ))

Я ничего не понял. Но вы создаёте проблему там, где её нет.

Что конкретно не так с ui_*.h?

То, что туда лазить нельзя, иначе замараешься. Но проблема не в этом. А в том, какой мне путь выбрать — все в одном скопе кучей как в ui_*.h или вложениями с ответственностью своей зоне + глобал для связи? И почему?

Я по прежнему ничего не понимаю.

Что вы подразумеваете под «скоупом»? Почему нельзя лазить в ui?

У меня нет уи. Я написал все руками изучая доки. И это не важно. Скоуп — область видимости. Чтобы при нажатии клавиши в окне, окно отсигналило воооон тому компоненту, и вон тому тоже. Или что при клике на кнопку закрылась вон та область, открылась эта и с правого угла выскочил ёжик и каак побежит по тулбару.

Вопрос. Класть все в кучу чтобы любой мог отсигналить кому угодно и слушать кого угодно или раскладывать их в иерархию + глобальный объект, через который они смогут делать то же самое (sender receiver)? Первый вариант мне не нравится потому, что все в куче. Второй потому, что лишняя сущность для связи. Еще варианты есть? Я же мало что знаю.

Всё равно не понимаю.

Есть виджет-родитель. У него, допустим, два дочерних элемента: лейбл и кнопка. В конструкторе обоих создаём и подключаем. Какие тут могут быть скоупы? Зачем тут нужен синглтон?

Мне нужно не только к ближайшим родителям-потомкам коннектить, но и к другим в других местах.

Тогда у виджета-родителя создаём сигналы и вручную пробрасываем. Вы эту задачу пытались решить через синглтон?

вручную пробрасываем

Какое отношение имеет «предок» к сигналу А, когда в нем есть разные дочерние виджеты, которые хотят А, Б, В, Г, Д и Е сигналы? По моему посредственное. Тем более что в другом предке висит еще десяток виджетов, желающих Г, Д, Е и Ж сигналы. Почему бы не скучковать их в одном месте полностью или обслуживающем, например, только: Г, Д, Е?

Или пробрасываем порождая еще один сигнал? Так очередь загадим.

Почему бы не скучковать их в одном месте полностью

Потому, что быдлокод. Что вы будете делать, когда у вас будет 100500 сигналов?

Объект/Виджет - это отдельная сущность. Нам не важно что у него внутри, хоть 100500 дочерних объектов. Он должен испускать только те сигналы, которые нам нужна на уровне выше.

Или пробрасываем порождая еще один сигнал? Так очередь загадим.

Какую очередь? «Преждевременная оптимизация - корень всех зол» - это как раз ваш случай. Если сигнал в пределах одного потока - то он стОит как и вызов обычной функции.

Потому, что быдлокод

Спорно. Аргументы ниже.

когда будет 100500 сигналов

Не будет. Потому что от обратного, будет мало сигналов и на каждый по одному слоту для работы с целевой группой. Или много слотов на один сигнал, что не отменяет необходимости в глобальном объекте хранящем целевые объекты.

Он должен испускать только те сигналы, которые нам нужна на уровне выше

Или я не распарсил, или реально всплывать/погружаться перебросом сигнала пока не достигнем цели? Это звиздец.

Какую очередь?

Ивент лупа.

Преждевременная оптимизация

Оптимизация это когда на асме кусок переписываешь.

Так мы не договоримся - покажите кусок кода.

Оптимизация это когда на асме кусок переписываешь.

Это маразм.

Три ветки:

widgetA->widgetB->widgetC
widgetA->widgetD->widgetE
widgetA->widgetF->widgetG

widgetE должен отсигналить к widgetC и widgetG:

connect(widgetE, SIGNAL(foo()), widgetC, SLOT(ok()));
connect(widgetE, SIGNAL(foo()), widgetG, SLOT(ok()));

Если что — вложенные виджеты публичны и доступны по цепочке, но, если я захочу поменять порядок и глубину вложенности цепочки...

Обычно это делается через проброс сигнала в A и затем уже к детям.

1) Да и не нужно. Достаточно сигналы пробросить.

2) Вы про синглтон?

3) Да. Проброс. Это совершенно нормальных подход. Посмотрите сорцы приложений.

сигналы пробросить, проброс это совершенно нормальный подход.

Можно псевдокод для моего примера?

про синглтон?

Да.

connect(widgetB, &WidgetB::someSignal, this, &WidgetA::someSignal);

и тд.

someSignal все же определенный сигнал, а не один на все случаи? Значит на каждый новый сигнал испускаемый откуда-то куда-то нужно протягивать новую цепочку?

но, если я захочу поменять порядок и глубину вложенности цепочки...

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

А в моем варианте, как сейчас на скорую руку, с экстерном не зная про Q_GLOBAL_STATIC: Самое:

class globalBlah : public QObject
{
    Q_OBJECT
    public:
        explicit globalBlah(QObject *parent);
        ~globalBlah();
    // global access
    QWidget *mainWindow;
    QWidget *a;
    QWidget *b;
    QWidget *c;
};

globalBlah Blah(0);

extern globalBlah Blah;

Blah.c = this;
connect(this, SIGNAL(foo()), Blah.a, SLOT(bar()))

1) Не засираем ивент луп мусорными сигналами.
2) Не зависим от вложенности и области видимости.
3) Легко и нативно доступно из тредов.
4) Меньше кода, гибкость, свобода.
5) Хочешь быть доступным — добавь себя сам.

Минусы?