On Saturday, 14 September 2013 01:08:09 CEST, Thomas Lübking wrote:
Fading version, replaces former patch.

Pure magic :). You rock. Nitpicks below.

+static const QString
trojita_opacityAnimation("trojita_opacityAnimation");

Construction shall hapen via QLatin1String (-DQT_NO_CAST_FROM_ASCII)

+    m_lastFocusedRecipient(NULL),

0 (or "nullptr" and an appropriate patch to CMakeLists.txt)

+ connect (qApp, SIGNAL(focusChanged(QWidget*, QWidget*)), SLOT(invalidateLastFocusedRecipient()));

- extra space before the parenthesis
- non-normalized signal signature
- the same applies to the code in ComposeWidget::scrollRecipients

+    animation->setDuration(333);

Way to go!

Well, I like the number, but I'm in general used to a non-fading stuff on my desktop. When I scroll a list with many recipients, the delay looks a bit intrusive here. I don't think there's a way to detect user's preferences on the number of effects and/or timeouts, so I suspect there's no easy way to better fit the desktop here -- I'm just mentioning this for completeness. The wow effect is still here :).

+        QWidget *toCC = m_recipients.at(i).first;

Strictly speaking, it's a "recipient widget" -- it could be a Bcc field, too.

+    if (o == ui->envelopeWidget)  {
+        if (e->type() == QEvent::Wheel) {
+            int v = ui->recipientSlider->value();
+            if (static_cast<QWheelEvent*>(e)->delta() > 0)
+                --v;
+            else
+                ++v;
+            ui->recipientSlider->setValue(v);
+            e->accept();
+            return true;
+        }
+        return false;
+    }

What about simply passing the event to the scrollbar (and eating it, of course)? That would eliminate the need to establish proper boundaries.

+    QWidget *m_lastFocusedRecipient;

I see that you're not using using it directly from anywhere -- good. You're still comparing addresses, though, and I wonder if it's possible that the original widget gets deleted and a new one gets allocated at the same address later on. That would lead to a wrong widget getting focus. Is that possible in the current code? Either way, I think that using a QPointer would be safer here.

Also, when the last recipient has focus and I scroll up, the focus moves to subject. I guess this is expected and by design -- I don't know what else to do.

Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Reply via email to