Local Event Loop

[Racheengel]

Зато на Alt-F4 нажать сможет легко.

Похоже, QGraphicsScene имеет "защиту" от этого во время драга. По крайней мере, у меня ничего не происходит, окно не закрывается.

[Igors]

То есть стало больше кода, появился фильтр эвентов, промежуточные переменные, и всё равно надо имплементировать hangleDrag() и hangleRelease()...
Не понятно, где мы выигрываем

А зачем Вы нарисовали onMouseReleased, onMouseMoved,  im_isDrag, m_lastEvent и.т.п. ? Вся эта ботва становится ненужной если у нас есть козырная IsMouseStillDown, и мы спокойно сосредоточим весь ф-ционал в одном hangleDrag, хотя бы так

Код

C++ (Qt)
void MyWindow::MouseListDown( QMouseEvent * e )
{
   if (!HandleListItemDrag(e)) 
    DoListSelection(e);
}
 

[Racheengel]

А как реализовать драг, не принимая ивенты от мыши?
Никак.
И это надо делать где то, хоть во внутреннем ивент-лупе, хоть во внешнем.
Кода меньше не станет.
Поэтому я не понимаю смысл "огород городить".

[Igors]

А как реализовать драг, не принимая ивенты от мыши?
Никак.

Как сказано в стартовом посте. GetMousePosition - не проблема, годится хотя бы QCursor::pos. Ну а можно и "развитОй социализм", напр

Код

C++ (Qt)
while (IsMouseStillDown()) {
  while (GetLocalEvent(e)) {
    switch (e->type()) {
      case QEvent::KeyPressed:
        if (CheckCancel(e))     // drag aborted ?
         return false;
    }
  }
 ... 
}
 

И это надо делать где то, хоть во внутреннем ивент-лупе, хоть во внешнем.
Кода меньше не станет.

Ну вот первая попавшаяся m_clickPosition. Одно дело когда это локальная переменная в методе - о ней можно просто забыть. И совсем другое когда это член класса за которым нужно следить в неск методах.

Поэтому я не понимаю смысл "огород городить".

Да все Вы поняли, по глазам вижу 

Вот правда реализовать IsMouseStillDown совсем не просто.

[Igors]

И притих.. Собсно реакция абсолютно нормальная и 100% естественная

А почему так никто не делает (я не видел)? Выходит все дураки а он один такой умный?

И сразу пошли аргументы "в одну калитку", мол, да тут ничего хорошего и нет и все такое.. А между тем вторичный цикл событий является (по меньшей мере) стандартным и хорошо известным приемом, почему я не могу его юзать в Qt

Вернемся к теме, как же реализовать IsMouseStillDown? Казалось бы, что тут хитрого - да жрать в фильтре все события мыша и клавы (возвращать true) пока не увидим MouseReleased. К сожалению, так не выходит. Беда в том что processEvents обрабатывает "пачку" событий, и MouseReleased может быть совсем не последним в этой пачке,  напр

- UpdateEvent
- MouseReleased
- MouseDoubleClick  // резвый юзер успел!

И что делать с последним MouseDoubleClick ? Сожрать нельзя - тогда double-click на айтем не будет открывать окно (причем подленько, "иногда"). И пропустить низзя - ведь тогда обработка будет вызвана в теле драга (пусть там ничего пока не драгнулось, но все равно из него надо выйти).

И шо делать  

[Racheengel]

А между тем вторичный цикл событий является (по меньшей мере) стандартным и хорошо известным приемом, почему я не могу его юзать в Qt

Кому известным? Где является?

И шо делать 

Перестать беспокоиться и начать жить А именно, использовать стандартный кутишный подход. Да, он не прозрачен. Но "покажите мне другие работающие".

[Igors]

Кому известным? Где является?

Мне известным со времен Вындоуз 3.0, Вам - не знаю. Используется везде, в том числе и в ядре Qt

А именно, использовать стандартный кутишный подход. Да, он не прозрачен.

А почему Вы думаете что я его не использовал? Но мне надоело с ним мучиться. Я хочу нормальные методы, по одному на драг, или даже глобальные ф-ции и вызывать их из разных окон. А не дурацкую "систему рычагов" с кучей переменных класса и бесконечными проверками state. Для этого по сути нужно написать одну ф-цию

Но "покажите мне другие работающие".

Так я и показал в стартовом посте

Перестать беспокоиться и начать жить  

Все-таки хочется быть молодым

[Racheengel]

И что делать с последним MouseDoubleClick ?

Но как раз DoubleClick не может прийти во время драга (если, конечно, драг не через правую кнопку мыши реализуется, что тоже может иметь смысл).
Это гарантированно реализовано на уровне самого фреймворка.

Я, кстати, не так давно намучился с кейсом, когда юзер во время драга ухитрялся нажимать правую кнопку.
Тогда вся чудо-система событий начинала сходить с ума, Qt пыталась одновременно и контексное меню показать, и драг продолжить.
Единственное разумное решение в этом случае - игнорировать ВСЕ события от кнопок мыши, кроме левой. Драг должен быть эксклюзивно блокирующей процедурой с т.з. действий юзера.

[Igors]

Но как раз DoubleClick не может прийти во время драга (если, конечно, драг не через правую кнопку мыши реализуется, что тоже может иметь смысл).
Это гарантированно реализовано на уровне самого фреймворка.

Приходит DoubleClick, сценарий такой:

- случился MousePress, приложение готовит драг (что может занять некоторое время) и вызывает processEvents

- но юзер ничего драгать не хотел, он отпустил мыша и снова его нажал, т.е. "двойной щелчок мыши" (боже как идиотски это звучит). Прочем это случилось ДО ТОГО как приложение вызвало processEvents

- теперь в processEvents сначала придут MouseReleased (напр для окна, потом для виджета) - и их надо пропускать, иначе будут неприятности (залипшие кнопари и.т.п.)

- но упр-е еще не вернулось из processEvents, и следующим придет DoubleClick

[Racheengel]

- случился MousePress, приложение готовит драг (что может занять некоторое время) и вызывает processEvents

Вот в этом и проблема. Драг надо начинать не по правому нажатию, а по первому движению после правого нажатия.

[Igors]

Вот в этом и проблема. Драг надо начинать не по правому нажатию, а по первому движению после правого нажатия.

У меня обычно по левой кнопке, правая contextual, но это не принципиально. Да, точнее/культурнее сначала дождаться "first motion"

Код

C++ (Qt)
if (!IsMouseMoved()) return false
while (IsMoiseStillDown()) {
...
}

Разница между этими двумя ф-циями лишь в ожидаемом событии (MouseMoved и MoiseReleased). Но от проблемы DoubleClick это не спасает, уже по MousePressed я должен что-то подрисовать (показывая "драг возможен") и сколько времени это займет - хз

Есть такая фишка, казалось бы "то что надо"

void QAbstractEventDispatcher::interrupt()
Interrupts event dispatching. The event dispatcher will return from processEvents() as soon as possible.

Но увы, она совсем не гарантирует "по одной не ошибешься", DoubleClick приходит в том же вызове processEvents

[Racheengel]

Если пришел дабл клик - надо игнорировать начало драга, т.к. левая кнопь не зажата уже.

[Igors]

Если пришел дабл клик - надо игнорировать начало драга, т.к. левая кнопь не зажата уже.

Не очень ясно как "игнорировать начало драга", ведь он уже "в процессе". Да и вообще обсуждение как-то выдохлось  

А помните давеча Вы тему создали, что-то про технологии. Как молодые люди блистали своими обширными познаниями! А тут победить несчастный дабл клик - и их всех как ветром сдуло, остался один собеседник, вероятно моего возраста. Вот уж неделю жду, ну кто же предложит очевидное решение что я реализовал. А узнать что-то (для себя) новое - уж и не помышляю

[tux]

Если пришел дабл клик - надо игнорировать начало драга, т.к. левая кнопь не зажата уже.

Ежели он пришёл, то значить кнопка ужо отпушшена. А, ежели так, то уже пришёл дроп.

[Racheengel]

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

Ну за Ваш возраст не знаю, а мне еще лет 25 и на пенсию

А дабл клик - "дело тонкое". Много геморроя с такими решениями, ибо много состояний. Тут либо "юзать что фреймворк дал", либо полностью свою логику писать. Только не миксить одно с другим, боже упаси...

Вот уж неделю жду, ну кто же предложит очевидное решение что я реализовал. А узнать что-то (для себя) новое - уж и не помышляю

Не знаю, для меня "очевидным" было решение на мышиных эвентах. "Работает же"