The applet doesn't work 100% identically compared to the buttons on a normal window

[trmdi]

I found this from this patch: kupiqu/SierraBreezeEnhanced#56
It still works correctly with normal KWin windows as well as the preview window in SystemSettings.

[kupiqu]

Interestingly enough, it worked for me until I restarted latte (including the update to kupiqu/SierraBreezeEnhanced#56).

Perhaps some heuristic failed?

[psifidotos]

The window buttons applet is a different case than the decorations preview kcm. So @trmdi you must describe me what your code is doing and I can tell you afterwards what is happening. I have not found any way to draw real deoration2 in the applet. It is not possible because a real decoration draws also the window title background.

[trmdi]

I just override the virtual function in the Decoration class.
https://github.com/kupiqu/SierraBreezeEnhanced/blob/2ea6819f8512dbd7b8902a24b26d8ec80b1d30f8/breezedecoration.cpp#L360

[psifidotos]

I don't think that can work with the applet

[psifidotos]

@trmdi please test again with latest master, there is a chance that d7b466e has fixed this

[trmdi]

Maybe, I'm about to tell you that when debugging I found that all buttons created by the applet has the same decoration which is a Breeze::Decoration object.

[trmdi]

Didn't work.
SBE only receives the mouse enter and leave event, not the hovermove.

[psifidotos]

https://github.com/psifidotos/applet-window-buttons/blob/master/libappletdecoration/previewbutton.cpp#L502

It should, shouldn't it?

[trmdi]

I don't know, I try adding a qDebug() << event->posF here and it doesn't show changes when moving mouse on the applet.

[psifidotos]

me neither, it should just work like all the rest signals

[trmdi]

Ah, it is the value of "e " which you send to decoration() is not true.
When I move on the applet:

• event->pos changes
• e->pos is a const.

Some numbers:

applet-buttons: event: QPointF(25,28)
applet-buttons: e: QPointF(179,161)
applet-buttons: event: QPointF(21,22)
applet-buttons: e: QPointF(179,161)
applet-buttons: event: QPointF(18,15)
applet-buttons: e: QPointF(179,161)
applet-buttons: event: QPointF(9,3)
applet-buttons: e: QPointF(179,161)

[psifidotos]

how about:

void PreviewButtonItem::hoverMoveEvent(QHoverEvent *event)
{
    if (!m_button) {
        return;
    }

    QPoint newPos (qBound((double)m_visualGeometry.left(), m_visualGeometry.left() + event->posF().x(), (double)m_visualGeometry.right()),
                   qBound((double)m_visualGeometry.top(), m_visualGeometry.top() + event->posF().x(), (double)m_visualGeometry.bottom()));

    QPoint oldPos (qBound((double)m_visualGeometry.left(), m_visualGeometry.left() + event->oldPosF().x(), (double)m_visualGeometry.right()),
                   qBound((double)m_visualGeometry.top(), m_visualGeometry.top() + event->oldPosF().x(), (double)m_visualGeometry.bottom()));

    //! this a workaround in order to send proper coordinates
    //! that confirm the button visual coordinates
    QHoverEvent e(event->type(),
                  newPos,
                  oldPos,
                  event->modifiers());

    QCoreApplication::instance()->sendEvent(decoration(), &e);
}

[trmdi]

Not work.
But I think you're right with the idea that the pos of the event sent to the decoration() is not correct.
We need something like:

e.posF.x() = some_width() * event->posF().x() / applet->width()

[trmdi]

Hmm, the problem is the geometry and layout are very different between the applet and the normal Decoration. So we can't send a right event to the decoration.

[psifidotos]

Send me a PR with what you are describing in order to test it out

[trmdi]

I don't know, but apply those 2 patches I've just sent fix all issues.

[psifidotos]

@trmdi do you still want d7b466e to stay in master or I can revert it?

[kupiqu]

As far as I can see, kupiqu/SierraBreezeEnhanced#58 only affects the window buttons applet and depends on #68 to be merged here. So before I merge kupiqu/SierraBreezeEnhanced#58 I would like to know if you are planning to merge #68. Thank you

[psifidotos]

@kupiqu I will merge it but I am waiting for a response from @trmdi

[trmdi]

d7b466e is still ok for me. Can you confirm it @kupiqu ?

[kupiqu]

d7b466e is still ok for me. Can you confirm it @kupiqu ?

I think what @psifidotos needs to know (correct me if wrong) is if #68 builds on top of d7b466e or if it is independent, in which case such commit (d7b466e) can be reverted.

As I didn't test #68, neither kupiqu/SierraBreezeEnhanced#58 I cannot really answer that question...

EDIT: I made what I think could be reverted (d7b466e) more explicit